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

Carmelo AMOROSO carmelo.amoroso at st.com
Wed Apr 20 14:09:26 UTC 2011


On 4/20/2011 3:07 AM, Maksim Rayskiy wrote:
> Peter,
> 
> I built ldso-future for mipsel with some very minor source tweaking,
> but the system panics immediately after starting usermode. I was not
> able to isolate the source of the crash yet.
> 
> Carmelo,
> 

Hi,

> I built the uClibc testsuite and ran it on uClibc-0.9.32-rc3 with my
> patch. There were some failures, but I do not think they were relevant
> to this particular problem. If you want I can post the full test run
> log.

it could be useful.

> BTW, pre-patch tst-cancel23 test hangs, with the patch it passes.
> 

fine :)

> Thanks,
> Maksim.
> 

cheers,
carmelo

> On Fri, Apr 15, 2011 at 11:40 AM, Peter Mazinger <ps.m at gmx.net> wrote:
>> Hi Maksim,
>>
>> I have kept ldso-future separate of future branch to allow Carmelo to add
>> his prelink branch to master after release, after that ldso-future (if the others devs agree) will be moved to master too (the future branch should not affect the prelink branch so much)
>>
>> If you look in elfinterp-common.c and/or compare mips/elfinterp.c with the
>> others, you'll realise, that there are much discrepancies, I did not touch them, since I could not check it, if it can at all boot.
>>
>> Regards, Peter
>> -------- Original-Nachricht --------
>>> Datum: Fri, 15 Apr 2011 10:18:50 -0700
>>> Von: Maksim Rayskiy <maksim.rayskiy at gmail.com>
>>> An: Peter Mazinger <ps.m at gmx.net>
>>> CC: Carmelo AMOROSO <carmelo.amoroso at st.com>, uclibc at uclibc.org
>>> Betreff: Re: Linking with uClibc-0.9.32-rc3 on mipsel is sensitive to shared libraries link order
>>
>>> 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.
>>>
>>> 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
>>>>
>>
>> --
>> 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