This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: suggestion for GCC (1)


On 08/02/2011 01:44, Ian Lance Taylor wrote:
Thomas Martitz<thomas.martitz@student.htw-berlin.de> writes:

Am 08.02.2011 00:04, schrieb Ian Lance Taylor:
ali hagigat<hagigatali@gmail.com> 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.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]