[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46322AFD.5000706@shadowen.org>
Date: Fri, 27 Apr 2007 17:55:25 +0100
From: Andy Whitcroft <apw@...dowen.org>
To: Christoph Lameter <clameter@....com>
CC: Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: 2.6.21-rc7-mm2 -- PPC link failure
Christoph Lameter wrote:
> On Thu, 26 Apr 2007, Andy Whitcroft wrote:
>
>>> Gcc 3.3 works just fine on other platforms like i386. This is more likely
>>> a platform issue. If we disable it then only for <= gcc 3.3 on ppc. If
>>> problems crop up with other platforms then we can expand on it.
>> I was thinking that it would be nasty to have a set of platform
>> specific, compiler specific ifdefs in here. I was more thinking of just
>> making this a BUG for all platforms. This does result in slightly later
>> detection but this is a constant mode only, so any bad use of kmalloc()
>> would be picked up on first boot in testing always.
>>
>> I think that would be sufficient and safe even against the worst
>> optimiser (none). Plus much less horrible to look at?
>
> The build time detection is quite important for NUMA since structures keep
> growing. I'd like to keep that. In fact I would really like a build time
> detection. If a too large kmalloc occurs then the compile should stop at
> that point and the kernel should not link at all.
>
> See my patch @ http://marc.info/?l=linux-kernel&m=117752927203466&w=2
Yeah I played with that for a bit last night to no good effect.
BUILD_BUG_ON simply becomes a noop if the optimiser doesn't really
really know that the thing its talking about is a real constant.
I assume that if it cannot be sure that it should constant fold the
number, it leaves it for runtime. Then the optimiser sees that the
thing is void and therefore removable and removes it. So no error.
Perhaps we need to enlist someone from gcc-land to tell us how to figure
out what its doing and massage it into working.
-apw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists