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 <p...@gmx.net> 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 <maksim.rays...@gmail.com> >>> An: Peter Mazinger <p...@gmx.net> >>> CC: Carmelo AMOROSO <carmelo.amor...@st.com>, uclibc@uclibc.org >>> 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 <p...@gmx.net> 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 <carmelo.amor...@st.com> >>>>> An: Maksim Rayskiy <maksim.rays...@gmail.com> >>>>> CC: uclibc@uclibc.org >>>>> 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 >>>>> <carmelo.amor...@st.com> 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 >>>>>>>> uClibc@uclibc.org >>>>>>>> http://lists.busybox.net/mailman/listinfo/uclibc >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> uClibc mailing list >>>>>>> uClibc@uclibc.org >>>>>>> http://lists.busybox.net/mailman/listinfo/uclibc >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> uClibc mailing list >>>>> uClibc@uclibc.org >>>>> 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 uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc