Hello,

I know of 2 problems in ldso-future:
1. I have hidden _start, some debuggers are looking for this symbol, maybe 
hiding should depend on DODEBUG
2. I made skip_args static (since we do not support yet the option), but that 
seems to make problems on some archs
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.

Peter 
-------- Original-Nachricht --------
> Datum: Wed, 20 Apr 2011 16:09:26 +0200
> Von: Carmelo AMOROSO <[email protected]>
> An: Maksim Rayskiy <[email protected]>
> CC: Peter Mazinger <[email protected]>, [email protected]
> 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 <[email protected]> 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 <[email protected]>
> >>> An: Peter Mazinger <[email protected]>
> >>> CC: Carmelo AMOROSO <[email protected]>, [email protected]
> >>> 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 <[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
> >>>>
> >>
> >> --
> >> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> >> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
> >>
> > 
> 

-- 
GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit 
gratis Handy-Flat! http://portal.gmx.net/de/go/dsl
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc

Reply via email to