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

[Carmelo AMOROSO]

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
>>
>