On 4/27/2011 12:23 PM, Peter Mazinger wrote: > Hi Carmelo, > Hi Peter,
>> 2. I made skip_args static (since we do not support yet the option), but >> that seems to make problems on some archs >> >> IIRC, this has some impact on prelink (specifically to have stand-alone >> mode working). > > I have thought, that stand-alone mode is not implemented yet ... > Is it really? > it is implemented in prelink branch indeed (as a prerequisite for prelink to work) >>> Jocke, should we make this a config option, any volunteer to disable it >> correctly in each arch's assembler code? >>> Will change this back to hidden. >>> >> >> What should we control by a config option ? sorry it is not so clear to >> me. > > I meant a config option to enable/disable stand-alone mode (running > ld-uClibc.so.0 <someapp>) > already available in prelink branch (637e2b2440f69e22932edd71bd2f0b1210dc32ea) > Peter > >> Carmelo >> >>> -------- Original-Nachricht -------- >>>> Datum: Wed, 20 Apr 2011 16:09:26 +0200 >>>> Von: Carmelo AMOROSO <[email protected]> >>>> An: Maksim Rayskiy <[email protected]> >>>> CC: Peter Mazinger <[email protected]>, [email protected] >>>> Betreff: Re: Linking with uClibc-0.9.32-rc3 on mipsel is sensitive to >> shared libraries link order >>> >>>> On 4/20/2011 3:07 AM, Maksim Rayskiy wrote: >>>>> Peter, >>>>> >>>>> I built ldso-future for mipsel with some very minor source tweaking, >>>>> but the system panics immediately after starting usermode. I was not >>>>> able to isolate the source of the crash yet. >>>>> >>>>> Carmelo, >>>>> >>>> >>>> Hi, >>>> >>>>> I built the uClibc testsuite and ran it on uClibc-0.9.32-rc3 with my >>>>> patch. There were some failures, but I do not think they were relevant >>>>> to this particular problem. If you want I can post the full test run >>>>> log. >>>> >>>> it could be useful. >>>> >>>>> BTW, pre-patch tst-cancel23 test hangs, with the patch it passes. >>>>> >>>> >>>> fine :) >>>> >>>>> Thanks, >>>>> Maksim. >>>>> >>>> >>>> cheers, >>>> carmelo >>>> >>>>> On Fri, Apr 15, 2011 at 11:40 AM, Peter Mazinger <[email protected]> wrote: >>>>>> Hi Maksim, >>>>>> >>>>>> I have kept ldso-future separate of future branch to allow Carmelo to >>>> add >>>>>> his prelink branch to master after release, after that ldso-future >> (if >>>> the others devs agree) will be moved to master too (the future branch >>>> should not affect the prelink branch so much) >>>>>> >>>>>> If you look in elfinterp-common.c and/or compare mips/elfinterp.c >> with >>>> the >>>>>> others, you'll realise, that there are much discrepancies, I did not >>>> touch them, since I could not check it, if it can at all boot. >>>>>> >>>>>> Regards, Peter >>>>>> -------- Original-Nachricht -------- >>>>>>> Datum: Fri, 15 Apr 2011 10:18:50 -0700 >>>>>>> Von: Maksim Rayskiy <[email protected]> >>>>>>> An: Peter Mazinger <[email protected]> >>>>>>> CC: Carmelo AMOROSO <[email protected]>, [email protected] >>>>>>> Betreff: Re: Linking with uClibc-0.9.32-rc3 on mipsel is sensitive >> to >>>> shared libraries link order >>>>>> >>>>>>> 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. >>>>>>> >>>>>>> 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 >>>>>>>> >>>>>> >>>>>> -- >>>>>> 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
