[PATCH] Get rid of the ARM variant choice in the menuconfig, take 2
raj.khem at gmail.com
Thu Apr 9 08:23:18 UTC 2009
On Thursday 09 April 2009 01:06:36 am Mike Frysinger wrote:
> On Thursday 09 April 2009 03:15:34 Khem Raj wrote:
> > On Thursday 09 April 2009 12:02:50 am Mike Frysinger wrote:
> > > On Wednesday 08 April 2009 18:03:55 Yann E. MORIN wrote:
> > > > As previously suggested, here is a patch that gets rid of the ARM
> > > > variant choice in the menuconfig.
> > > >
> > > > Unlike the previous submission, the endianness is still passed down to
> > > > the compiler and linker.
> > > >
> > > > This patch is just a proof of concept, to serve as a base of
> > > > discussion. Should this proove the correct aproach, then the other
> > > > architectures could then also see their variant choice removed.
> > >
> > > thanks ... unless there's any other input/complaints/whatever, i'll merge
> > > this
> > Few concerns that I have
> > These options provided some uniqueness that was to a particular CPU.
> maintaining a list of "random variant has XXX features" is duplicating what
> gcc can (should) already be telling us
> > Like mmu or mmuless
> the number of variants that declare "i have no mmu" is pretty low. i dont
> think it's a big deal to make people deselect the "do you want to utilize the
> mmu" option. it's fairly hard to screw this up.
> > thumb or not thumb like cortex-m series does not support
> > arm mode at all. bx instruction in not supported on all architectures.
> > What abi to chose when building iwmmxt with old abi. I think leaving all
> > these individually configurable could bring more trouble because people
> > could get them wrong easily if there are more knobs.
> expecting people to know about ABI/EABI or arm/thumb mode is reasonable imo.
> adding knobs for significant features is one thing, but maintaining a constant
> binding of variant<->feature set is a never ending pain.
I think we could get the features like mtune and march out and let users specify them
but IMO I see some value in leave the others in bundle
to form the support that a particular variant has which is not generic. e.g. cortex-m3 case.
then we do not have to add a new variant just because its using a different mtune march
> doesnt gcc already expose BX support via defines in the toolchain ?
I don't think so. You have to synthesize it like arm glibc port does
#if (!defined (__ARM_ARCH_2__) && !defined (__ARM_ARCH_3__) \
&& !defined (__ARM_ARCH_3M__) && !defined (__ARM_ARCH_4__))
# define __USE_BX__
> then we
> could get rid of the USE_BX build option completely.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part.
More information about the uClibc