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

Reply via email to