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