[Top] [All Lists]

Re: CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20

To: Franck Bui-Huu <>
Subject: Re: CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20
From: "Maciej W. Rozycki" <>
Date: Wed, 26 Sep 2007 15:49:41 +0100 (BST)
Cc: Martin Michlmayr <>,, Atsushi Nemoto <>
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <> <> <> <>
On Wed, 26 Sep 2007, Franck Bui-Huu wrote:

> Except that if CONFIG_BUILD_ELF64 is set then we assume that the kernel
> is linked in XKPHYS which results in Martin's crash since his kernel is
> linked in CKSEG0.
> If you can recall that was done for a micro-optimization in __pa() but it
> was a huge mistake because it relies on the configuration of BUILD_ELF64
> to be setup correctly by the user... So in this case there's no point to
> set CONFIG_BUILD_ELF64='y' since it makes the kernel bigger and slower.
> But it used to work until my change, so my own fault.

 While, as expressed previously, the assumption of CONFIG_BUILD_ELF64 
meaning XKPHYS mapping is questionable, a requirement for the user to 
somehow magically know that the two became related somehow is 
unreasonable.  Especially as in many cases people just copy an old .config 
over to a new version of the kernel and run `make oldconfig'; I have 
certainly not done anything else for years.

 Given the dependency is quite straightforward it could have been sorted 
out with a reverse dependency in Kconfig based on the load addresses 
specified in Makefile -- boring, but easily done.  That assuming the 
failure of -msym32 resulting from the use of an older unsupported 
toolchain would be reported as fatal to the user, together with 
information of which versions are the minimum.

 Of course requiring a different version of the toolchain based on whether 
XKPHYS or KSEG0 mapping is used (i.e. newer for the latter!) is 
questionable too, but that is a different matter.


<Prev in Thread] Current Thread [Next in Thread>