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, 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. BTW, pre-patch tst-cancel23 test hangs, with the patch it passes. Thanks, Maksim. 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