Hi Carmelo, > 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? > > 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>) 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 -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
