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 27 05:40:57 UTC 2011
On 4/23/2011 1:19 PM, Peter Mazinger wrote:
> Hello,
>
Hi Peter,
> I know of 2 problems in ldso-future:
> 1. I have hidden _start, some debuggers are looking for this symbol, maybe hiding should depend on DODEBUG
> 2. I made skip_args static (since we do not support yet the option), but that seems to make problems on some archs
IIRC, this has some impact on prelink (specifically to have stand-alone
mode working).
> Jocke, should we make this a config option, any volunteer to disable it correctly in each arch's assembler code?
> Will change this back to hidden.
>
What should we control by a config option ? sorry it is not so clear to me.
> Peter
Carmelo
> -------- Original-Nachricht --------
>> Datum: Wed, 20 Apr 2011 16:09:26 +0200
>> Von: Carmelo AMOROSO <carmelo.amoroso at st.com>
>> An: Maksim Rayskiy <maksim.rayskiy at gmail.com>
>> CC: Peter Mazinger <ps.m at gmx.net>, uclibc at uclibc.org
>> Betreff: Re: Linking with uClibc-0.9.32-rc3 on mipsel is sensitive to shared libraries link order
>
>> 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