Messages in this thread | | | Subject | Re: [PATCH] x86: do not expose CONFIG_BSWAP to userspace | From | Harvey Harrison <> | Date | Wed, 28 Jan 2009 14:38:34 -0800 |
| |
On Wed, 2009-01-28 at 14:15 -0800, H. Peter Anvin wrote: > Harvey Harrison wrote: > > I'm afraid my knowledge of gcc compiler flags for various models is > > lacking, I used i486 as suggested, just wanted to make sure I understood > > you corectly. > > You did, but I misremembered... instead of having the __i386__, > __i486__, __i586__, __i686__ being an additive chain as would make > sense, gcc just has __i386__ plus whichever corresponds to the -march= > option. I keep forgetting this because it's just so incredibly dumb. > > Bloody hell. This really f*cks thing up.
> What's worse, they seem to simply be adding new options, so at this > point you'd actually need something like: > > # if defined(__i486__) || defined(__i586__) || defined(__i686__) || \ > defined(__core2__) || defined(__k8__) || defined(__amdfam10__) > > Worse, there isn't any kind of macro that can be used to compare for a > negative (i.e. not i386).
Well, that's unfortunate, how about we just export the BSWAP version unconditionally and hope pure i386 just goes away someday?
> > This obviously is screaming to be abstracted away into a header of its > own, but it really can't be done cleanly as far as I can tell because of > this particular piece of major gcc braindamage. > > So, one ends up doing something like: > > #ifdef __i486__ > # define __CPU_HAVE_BSWAP > #endif > #ifdef __i586__ > # define __CPU_HAVE_BSWAP > #endif > > ... and so on, and have to keep this up to date with the latest > inventions of the gcc people. *Sob.*
Unpleasant indeed. Is there a byteswap builtin in gcc? At least AVR32 seems to use it, but perhaps it's not generally exposed...perhaps we could ask the gcc-folk?
Harvey
| |