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 12:02:03 UTC 2011
On 4/27/2011 12:23 PM, Peter Mazinger wrote:
> Hi Carmelo,
>
Hi Peter,
>> 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).
>
> I have thought, that stand-alone mode is not implemented yet ...
> Is it really?
>
it is implemented in prelink branch indeed (as a prerequisite for
prelink to work)
>>> 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.
>
> I meant a config option to enable/disable stand-alone mode (running ld-uClibc.so.0 <someapp>)
>
already available in prelink branch
(637e2b2440f69e22932edd71bd2f0b1210dc32ea)
> 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
>>>>>>
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> uClibc mailing list
>> uClibc at uclibc.org
>> http://lists.busybox.net/mailman/listinfo/uclibc
>
More information about the uClibc
mailing list