weak symbols

Carmelo Amoroso carmelo.amoroso at st.com
Thu Oct 31 04:33:49 UTC 2013


Hi Nicolas,

On 10/30/2013 7:10 PM, Nicolas Sauzede wrote:
> Hi Rich,
>
> Thanks for your answer.
> In fact, my 'abort' example was just to demonstrate the weak issue
> scenario.
> We are indeed facing this issue with a lot of other symbols duplication
> when
> repurposing the uclibc as a semihosting lib c for a custom embedded
> linux port.
> The fact is that the linux kernel defines a lot of "standard" symbols
> for its own use,
> such as : memcpy, memmove, strlen, strnlen, sigprocmask, ...
> So we had to modify uclibc to turn these symbols to weak, to let linux
> use its own
> implementation.
>
> Note that I understand that uclibc internally still uses __GI_ symbols,
> which is expected.
> I just do not understand why *some* symbols of uclibc are defined weak,
> and some
> other not.

because the uClibc itself could provide a different implementation for 
example in libc or in libpthread depending if you are using threads *so 
you are linking -lpthread) or not.

> And in my tests against newlib and glibc, it appeared that, at least for
> 'abort', they
> both define it as weak, hence my question here, to more about the weak
> rationale of uclibc..

[amorosoc at lxmcdt5 /opt/STM/STLinux-2.4/devkit]readelf -s 
armv7/target/lib/libc.so.6 | grep abort
    494: 0002b3ec   772 FUNC    GLOBAL DEFAULT   11 abort@@GLIBC_2.4
   6734: 0002b3ec   772 FUNC    LOCAL  DEFAULT   11 __GI_abort
   8294: 0002b3ec   772 FUNC    GLOBAL DEFAULT   11 abort

In my build (glibc 2.10.2) it's strong.

> I would expect a lib c to either define all 'standard' symbols as strong
> if they should NOT
> be overriden by the user, or all as weak, to let the user override them.
> But here we seem to have a mix of the two, and I wanted to understand...
>
> BR,
> NS.
>

Cheers,
Carmelo

> Le 10/30/2013 6:16 PM, Rich Felker a écrit :
>> On Wed, Oct 30, 2013 at 04:13:10PM +0100, Nicolas Sauzede wrote:
>>> Hello,
>>>
>>> This is my first post to the uClibc mailing-list.
>>> I have a question related to weak API symbols of the uClibc.
>>>
>>> I have noticed that, when linking a static binary against the
>>> uClibc, that certain symbols,
>>> such as 'abort', are not defined as weak symbol.
>>> The end result is that this kind of trivial program my_abort.c :
>> Redefining any function in the standard library (formally, in the
>> namespace reserved for external identifiers) invokes undefined
>> behavior. While it would be possible to support this usage for some
>> functions (often it's supported for the malloc functions), in general
>> it's impossible (or at least impractical) to support this kind of
>> usage.
>>
>> Note that even if you could override the abort symbol like you're
>> trying to do, this would not cause uclibc-internal usage of abort to
>> call your function. The reason is exactly the same reason you're
>> getting the error: uclibc references it through the internal __GI_
>> prefixed symbol.
>>
>> I have no idea whether the uclibc maintainers are willing or able to
>> support this usage for abort, but your overriding it is broken usage
>> anyway.
>>
>> Rich
>
> _______________________________________________
> uClibc mailing list
> uClibc at uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc
>



More information about the uClibc mailing list