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@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
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
