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 > _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
