On Wed, Dec 08, 2004 at 06:22:01PM +0000, Richard Earnshaw wrote:
> On Wed, 08 Dec 2004 10:26:08 CST, James Chacon <jmc@netbsd.org>  wrote:
> > On Wed, Dec 08, 2004 at 11:50:18AM +0000, Richard Earnshaw wrote:
> > > The intention behind this change was to make all user-land code the same
> > > across all ARM platforms.  Doing as you suggest would require having
> > > different compiler binaries on each machine.  It then all goes downhill
> > > from there.
> > 
> > It shouldn't be that case. MACHINE/MACHINE_ARCH are things which don't need
> > exposing to userland at all. If something in userland needs them use
> > sysctl/uname(3) to get them.
> > 
> > This should line up w. how other shared archs do things (ala m68k, powerpc,
> > mips, etc) and none of them override MACHINE to some generic setting.
> 
> And how do you build uname into a cross compiler?  Answer: you can't.  So 
> it *has* to be built into the compiler statically, and then the only 
> answer that fits the one binary works on all platforms rule is to use 'arm'
> 

Huh? You setup the cross compiler by passing it args based on it's to
be configured. You don't need MACHINE/MACHINE_ARCH defined to do that. 

Somehow all the powerpc ports get cross compilers builts for them as 

powerpc--netbsd-gcc

Yet they don't have MACHINE="powerpc" forced on in userland. They currently
report MACHINE=macppc or MACHINE=sandpoint, etc and yet somehow have a common
toolchain regardless..i.e. that compiler produces the same binary/libraries
across all powerpc ports no matter which ones it's configured for. As part
of doing the 2.0 release I binary diffed all binaries on common archs and
they all line up. The only reason I found arm was because xman was embedding
MACHINE directly in the binary when it should have been using uname(3) and
arm didn't seem to exhibit that behavior. So actually setting it this way
causes more problems then good because it'll hide cases in userland where
people are using MACHINE and shouldn't be.

Basically there is *zero* reason MACHINE/MACHINE_ARCH need to be exposed to
userland that I can see. Even in the arm case for _KERNEL/KERNEL it sets
these correctly, so treating one arch as "special" from all the rest of
the common archs seems a bit ridiculous.

Providing a concrete example of where something in userland *requires*
MACHINE might show it's needed. Otherwise it should be expunged from view.

James