Linking with uClibc-0.9.32-rc3 on mipsel is sensitive to shared libraries link order
Carmelo AMOROSO
carmelo.amoroso at st.com
Mon Apr 18 06:56:04 UTC 2011
On 4/15/2011 7:18 PM, Maksim Rayskiy wrote:
> 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.
>
Your patch is fine, and currently it is the best way to fix.
I'd suggest you to run the uClibc suite and report any issues may be
caused by the protected symbol new code, as you have already done.
Thanks,
Carmelo
> On Fri, Apr 15, 2011 at 7:40 AM, Peter Mazinger <ps.m at gmx.net> 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 <carmelo.amoroso at st.com>
>>> An: Maksim Rayskiy <maksim.rayskiy at gmail.com>
>>> CC: uclibc at uclibc.org
>>> 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
>>> <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
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> uClibc mailing list
>>> uClibc at uclibc.org
>>> 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
>>
>
More information about the uClibc
mailing list