Linking with uClibc-0.9.32-rc3 on mipsel is sensitive to shared libraries link order
Maksim Rayskiy
maksim.rayskiy at gmail.com
Wed Apr 20 01:07:47 UTC 2011
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 <ps.m at 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.rayskiy at gmail.com>
>> An: Peter Mazinger <ps.m at gmx.net>
>> CC: Carmelo AMOROSO <carmelo.amoroso at st.com>, uclibc at 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 <ps.m at 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.amoroso at st.com>
>> >> An: Maksim Rayskiy <maksim.rayskiy at gmail.com>
>> >> CC: uclibc at 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.amoroso at 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 at uclibc.org
>> >> >>> http://lists.busybox.net/mailman/listinfo/uclibc
>> >> >>>
>> >> >>
>> >> >> _______________________________________________
>> >> >> uClibc mailing list
>> >> >> uClibc at uclibc.org
>> >> >> http://lists.busybox.net/mailman/listinfo/uclibc
>> >> >>
>> >> >
>> >>
>> >> _______________________________________________
>> >> uClibc mailing list
>> >> uClibc at 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
>
More information about the uClibc
mailing list