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

[Maksim Rayskiy]

Carmelo,

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;

}

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.
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++;

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
>