On Sun, Apr 17, 2011 at 11:56 PM, Carmelo AMOROSO <[email protected]> wrote: > On 4/15/2011 7:18 PM, Maksim Rayskiy wrote: >> Hi Peter, >> >> Of course having mips converge with the common code would be great. >> And I could help you with testing ldso-future on mips platform. I will >> probably need some guidance from you on test procedure. >> What is the timeline for bringing ldso-future to the mainline? Since >> the problem I reported affects our production code, I will need a >> short-term solution as well, so I will submit the patch to the current >> tree anyway. >> >> Thanks, >> Maksim. >> > > Your patch is fine, and currently it is the best way to fix. > I'd suggest you to run the uClibc suite and report any issues may be > caused by the protected symbol new code, as you have already done.
there are more cases in mips that should be fixed along with this one given I find some time I will enhance it. As such this wont hurt though > > Thanks, > Carmelo > > >> On Fri, Apr 15, 2011 at 7:40 AM, Peter Mazinger <[email protected]> wrote: >>> Hi, >>> >>> I would propose to look into the changes I added to ldso-future branch and >>> try to "commonize" mips. It is the most divergent arch (less common code >>> used). I do not have any mips around to check if it would at all boot if I >>> would "commonize" it's elfinterp.c >>> >>> Peter >>> -------- Original-Nachricht -------- >>>> Datum: Fri, 15 Apr 2011 16:35:18 +0200 >>>> Von: Carmelo AMOROSO <[email protected]> >>>> An: Maksim Rayskiy <[email protected]> >>>> CC: [email protected] >>>> Betreff: Re: Linking with uClibc-0.9.32-rc3 on mipsel is sensitive to >>>> shared libraries link order >>> >>>> On 4/15/2011 2:11 AM, Maksim Rayskiy wrote: >>>>> Carmelo, >>>>> >>>> >>>> Hi Maksim, >>>> >>>>> The test case is quite simple. The following code >>>>> >>>>> #include <stdio.h> >>>>> #include <pthread.h> >>>>> >>>>> int main(int argc, char *argv[]) >>>>> { >>>>> pthread_cond_t cond; >>>>> >>>>> printf("begin\n"); >>>>> pthread_cond_init(&cond, NULL); >>>>> printf("end\n"); >>>>> >>>>> return 0; >>>>> >>>>> } >>>>> >>>> >>>> ok >>>> >>>>> Works when compiled as: >>>>> mipsel-linux-gcc -Os -fno-builtin -Wall -g -lpthread -lc test.c -o >>>> mytest >>>>> but hangs when library order is reversed: >>>>> mipsel-linux-gcc -Os -fno-builtin -Wall -g -lc -lpthread test.c -o >>>> mytest >>>>> >>>>> I looked at ldso/ldso/mips/elfinterp.c per Filippo's suggestion and >>>>> saw that there are several cases when _dl_find_hash() does not have >>>>> sym_ref parameter set. >>>> >>>> yes, you're right. >>>> >>>> >>>>> I do not claim to understand the details of the code, but the >>>>> following patch seems to solve the problem on my platform: >>>>> >>>>> diff --git a/ldso/ldso/mips/elfinterp.c b/ldso/ldso/mips/elfinterp.c >>>>> index 2886f33..82f740d 100644 >>>>> --- a/ldso/ldso/mips/elfinterp.c >>>>> +++ b/ldso/ldso/mips/elfinterp.c >>>>> @@ -378,8 +378,11 @@ void >>>>> _dl_perform_mips_global_got_relocations(struct elf_resolve *tpnt, int >>>>> lazy) >>>>> *got_entry += (unsigned long) >>>>> tpnt->loadaddr; >>>>> } >>>>> else { >>>>> + struct symbol_ref sym_ref; >>>>> + sym_ref.sym = sym; >>>>> + sym_ref.tpnt = NULL; >>>>> *got_entry = (unsigned long) >>>>> _dl_find_hash(strtab + >>>>> - sym->st_name, tpnt->symbol_scope, >>>>> tpnt, ELF_RTYPE_CLASS_PLT, >>>> NULL); >>>>> + sym->st_name, tpnt->symbol_scope, >>>>> tpnt, ELF_RTYPE_CLASS_PLT, >>>> &sym_ref); >>>>> } >>>>> >>>>> got_entry++; >>>>> >>>> >>>> the fix is ok, indeed in this case the sym_ref is missing. >>>> >>>> When we've added protected symbols support for all archs we indeed have >>>> missed this change. >>>> >>>> For all the other occurrences of dl_find_hash in MIPS where sym_ref is >>>> missing have to be double checked, and I'm sorry, I do not know MIPS at >>>> all. >>>> >>>> Please, post a proper git patch and I'll push it. >>>> >>>> Thanks, >>>> Carmelo >>>> >>>> >>>> >>>>> I did not run any tests other than my test case. Could you guys please >>>>> review the patch? >>>>> >>>>> Thanks, >>>>> Maksim. >>>>> >>>>> On Thu, Apr 14, 2011 at 1:55 AM, Carmelo AMOROSO >>>> <[email protected]> wrote: >>>>>> On 4/13/2011 11:06 PM, Maksim Rayskiy wrote: >>>>>>> Hello, >>>>>>> >>>>>>> It has been reported against uClibc-0.9.32-rc1 that when linking an >>>>>>> executable with shared libraries on mipsel platform depending on the >>>>>>> order of the libraries in the linker command line you may end up with >>>>>>> an application which hangs on the first call to the shared library. >>>>>>> >>>>>>> http://lists.uclibc.org/pipermail/uclibc/2011-January/044611.html >>>>>>> >>>>>>> The problem was attributed to lack of protected symbols support for >>>>>>> mipsel which was added in rc2. >>>>>>> I retested both rc2 and rc3 using the same test case as in original >>>>>>> post and the problem is still there, as far as I can tell. >>>>>>> >>>>>>> Was anybody able to verify that adding protected symbols support for >>>>>>> all architectures fixed the problem on mips? >>>>>>> >>>>>>> Thanks, >>>>>>> Maksim. >>>>>> >>>>>> Hi, >>>>>> could you post again (in this thread) the test cases ? >>>>>> >>>>>> Thanks, >>>>>> Carmelo >>>>>> >>>>>>> _______________________________________________ >>>>>>> uClibc mailing list >>>>>>> [email protected] >>>>>>> http://lists.busybox.net/mailman/listinfo/uclibc >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> uClibc mailing list >>>>>> [email protected] >>>>>> http://lists.busybox.net/mailman/listinfo/uclibc >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> uClibc mailing list >>>> [email protected] >>>> http://lists.busybox.net/mailman/listinfo/uclibc >>> >>> -- >>> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir >>> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de >>> >> > > _______________________________________________ > uClibc mailing list > [email protected] > http://lists.busybox.net/mailman/listinfo/uclibc > _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
