[PATCH 03/12] nptl/Makefile.in: Append $(SYMBOL_PREFIX) to symbol names

Bernhard Reutner-Fischer rep.dot.nop at gmail.com
Thu Mar 7 18:20:33 UTC 2013


On 22 February 2013 12:34, Markos Chandras <markos.chandras at gmail.com> wrote:
> On 21 February 2013 17:05, Markos Chandras <markos.chandras at gmail.com> wrote:
>> On 21 February 2013 15:23, Bernhard Reutner-Fischer
>> <rep.dot.nop at gmail.com> wrote:
>>> On 21 February 2013 16:07, Markos Chandras <markos.chandras at gmail.com> wrote:
>>>> On 21 February 2013 14:03, Bernhard Reutner-Fischer

>>>> It's needed by the Meta arch port which I just submitted. Meta
>>>> prefixes symbols with "_". See the Rules.mak changes in the [07/12]
>>>> patch (once it reaches the mailing list). It's also needed by
>>>> h8300,bfin,i960 and v850 which also have SYMBOL_PREFIX=_
>>>
>>> ok, and why does it work for aforementioned fini, or do you just support static?
>>
>> Hi Bernhard,
>>
>> Now that I think about it, this patch is not needed. binutils 2.22 was
>> "fixed" to not take into account the leading "_" underscore for arches
>> anymore so there should be no problem during the linking phase. I will
>> double check that removing this patch does not break anything.
>
> Hi Bernhard,
>
> I've done some tests. It seems it is needed in both cases. if the
> linker does not find the symbol passed in -init/-fini parameters then
> it uses the default one. That surprised me as I was expecting a link
> failure instead of silently use the default symbol. So I looked at the
> binutils code and I observed the following in bfd/elflink.c
>
>       /* If there are initialization and/or finalization functions to
>          call then add the corresponding DT_INIT/DT_FINI entries.  */
>       h = (info->init_function
>            ? elf_link_hash_lookup (elf_hash_table (info),
>                                    info->init_function, FALSE,
>                                    FALSE, FALSE)
>            : NULL);
>
> So, if I understand this correctly, if the symbol passed in the -init
> parameter can't be resolved, then this code returns NULL and no
> DT_INIT entry is created. In other words, my libpthread.so.0 contains
> the DT_INIT entry correctly (as it is prefixed with $(SYMBOL_PREFIX)
> whereas libdl.so doesn't have a DT_FINI one even though it should
> (assuming LDSO_NO_CLEANUP is not set)
>
> After prefixing dl_cleanup with $(SYMBOL_PREFIX) a DT_FINI entry is
> created for libdl.so. Thanks for noticing.

Mike,

on the 0.9.33 branch, i now pushed this as
0600966321c011c31edbb60945bbdca3fa34b7cb
I seem to be confused, however. Can you have a look at bfin,
{_,}_dl_start resolution,
please (i don't have a bfin toolchain at hand right now)?

TIA && cheers,


More information about the uClibc mailing list