On 08/02/2011 01:44, Ian Lance Taylor wrote:
Thomas Martitz<thomas.martitz@xxxxxxxxxxxxxxxxxxxxx> writes:
Am 08.02.2011 00:04, schrieb Ian Lance Taylor:
ali hagigat<hagigatali@xxxxxxxxx> writes:
A necessary feature for GCC is to compile C/Assembly programs without
standard libraries for Intel architectures.
This feature can not and will not be implemented. Some supporting
routines are always required, particularly for gcc extensions like
nested functions and __attribute__ ((cleanup)).
IIRC the functions Ali mentioned (mem*) are the only required ones to
build working binaries without C library (i.e. for bare metal
targets). We do it this way at Rockbox.
Do you not use any sort of libc? I do embedded programming on a number
of targets, and while I avoid most of libc (there's seldom any evil
"malloc" or "printf" calls in my code), some of it is useful.
But I wonder why, the mem* functions are trivial to implement in plain
C so why does one need to provide them?
I took ali to be asking to build without any libraries at all, including
libgcc, which is what you get when you use -nostdlib. That can't work.
On most of the targets I use, libgcc is essential for supporting the
language itself (if your target doesn't have division instructions, for
example, then the supporting library functions are in libgcc). My
understanding is that libgcc contains what is needed for the C language,
but is not supposed to contain anything from the C standard library.
I think you are talking about the case where we do use libgcc, but don't
use libc. In other words: why don't we provide memcpy, etc., in libgcc,
or, rather, just call libgcc-specific routines? The answer is that we
expect the library provider to have a highly optimized version of those
functions. That is certainly the case when using glibc on GNU/Linux.
Since the library provider should already have a highly optimized
version, gcc doesn't bother providing one itself.
The optimal implementation of something like memcpy is highly dependent
on the target, so I agree it doesn't make sense to try to put it libgcc.
Even for the same architecture, "optimised" will mean different things
on different platforms. For a small ARM microcontroller, "optimised"
will mean "small" - for an ARM netbook, "optimised" will mean "fast".
The memcpy implementations in the target libc will presumably have an
appropriate algorithm.
Of course we could still arrange to provide simple versions in some
additional library which is only linked after libc. I would not be
opposed to that. Real C programs, though, almost always call memcpy and
friends themselves, and real C programs always require some level of
supporting code. The current situation doesn't really bother me.
Doesn't gcc treat functions like memcpy as builtins? Or is that only if
you explicitly write __builtin__memcpy? I would have thought that in
many cases, a builtin version can be a lot smaller and faster than
library code, since the compiler often knows about things like alignment
and sizes and can thus generate better code.
