On 4/23/2011 1:19 PM, Peter Mazinger wrote: > Hello, > Hi Peter,
> I know of 2 problems in ldso-future: > 1. I have hidden _start, some debuggers are looking for this symbol, maybe > hiding should depend on DODEBUG > 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). > 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. > 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
