David Miller wrote:
From: Scott Wood <[EMAIL PROTECTED]>
Date: Fri, 02 May 2008 17:16:07 -0500
If GCC generates a call to a libgcc function that calls a libc function,
I'd consider that a pretty serious bug, given that said libc function is
likely to consist of GCC-generated code, which could call the same
libgcc function, which calls the libc function, etc.
Not really, there are several interfaces in libgcc that need some
runtime help from the C library or the dynamic linker.
For example, EH frame support.
...which is in libgcc_eh, not libgcc, and is in support of features not
found in the language that libc is implemented in, avoiding any
possibility of a cyclic dependency. And the sort of libc functions it
uses are basic, standard things like memcpy and malloc. Much easier and
more stable to implement than the internal libgcc interface.
You really don't know what you're talking about.
Yawn.
I'd say problems are more likely if you use nonstandard implementations
of GCC internals...
The kernel is a special environment. Therefore even if you start
linking with libgcc, it is inevitable that you will need some
changed local version for some of those routines in the kernel.
Such as?
-Scott
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
