Linking with uClibc-0.9.32-rc3 on mipsel is sensitive to shared libraries link order

Peter Mazinger ps.m at gmx.net
Wed Apr 27 10:23:01 UTC 2011


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 <carmelo.amoroso at st.com>
> >> An: Maksim Rayskiy <maksim.rayskiy at gmail.com>
> >> CC: Peter Mazinger <ps.m at gmx.net>, uclibc at uclibc.org
> >> 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 <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
> >>>>
> >>>
> >>
> > 
> 
> _______________________________________________
> uClibc mailing list
> uClibc at uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc

-- 
NEU: FreePhone - kostenlos mobil telefonieren und surfen!			
Jetzt informieren: http://www.gmx.net/de/go/freephone


More information about the uClibc mailing list