weak symbols

Nicolas Sauzede nicolas.sauzede at st.com
Wed Oct 30 18:10:13 UTC 2013


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.
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..
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.

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



More information about the uClibc mailing list