[PATCH] Get rid of the ARM variant choice in the menuconfig, take 2

[Khem Raj]

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
value. 

> 
> 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__
#endif


> then we 
> could get rid of the USE_BX build option completely.
> -mike
> 

-- 
Khem Raj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/uclibc/attachments/20090409/82ae0aa4/attachment.pgp>