On 02/01/2008 03:46 AM, Jakub Jelinek wrote:
On Thu, Jan 31, 2008 at 07:50:42PM -0500, Kyle McMartin wrote:
> On Thu, Jan 31, 2008 at 04:47:55PM -0800, Roland McGrath wrote:
>>> Why are we building kernels with this broken compiler?
>>>
>>>
http://bugzilla.kernel.org/show_bug.cgi?id=8501
>>>
>>>
http://koji.fedoraproject.org/koji/getfile?taskID=388196&name=build.log
>> Why are we building these broken kernels with our shiny new compiler?
>>
> Does using -ffreestanding fix these references to libgcc? I notice
> we're not using it when we build x86 or powerpc kernels, where we see
> this...
No, even -ffreestanding assumes libgcc is used. libgcc.a is mostly[1]
self-contained and assumed to be present in both -fhosted and -ffreestanding
linking. This is nothing new, has been like that for many years.
AFAIK kernel on several architectures uses libgcc.a, on those where it
intentionally decides not to do that, it either needs to supply its own
implementation of the needed entrypoints, or make sure they are not needed.
In this case you should put in an asm optimization barrier into the loop
to avoid optimizing the loop into modulo. See the gcc PR opened for it.
The below patch fixes it too, but that just leads to the next error
(on ppc64):
drivers/input/mouse/psmouse-base.c:45: error: __param_proto causes a section type
conflict
Was someone supposed to test building the kernel package with the new
compiler before making it the default?
--- linux-2.6.24.noarch.orig/include/linux/time.h
+++ linux-2.6.24.noarch/include/linux/time.h
@@ -169,7 +169,7 @@ extern struct timeval ns_to_timeval(cons
* @a: pointer to timespec to be incremented
* @ns: unsigned nanoseconds value to be added
*/
-static inline void timespec_add_ns(struct timespec *a, u64 ns)
+static inline void timespec_add_ns(struct timespec *a, volatile u64 ns)
{
ns += a->tv_nsec;
while(unlikely(ns >= NSEC_PER_SEC)) {