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

[Khem Raj]

On Thursday 09 April 2009 10:12:19 am Yann E. MORIN wrote:
> Khem, Mike,
> All,
> 
> On Thursday 09 April 2009 10:23:18 Khem Raj wrote:
> > 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.
> 
> The idea is really to rely on the user to correctly set up the compiler,
> so that it uses:
> 
> - the correct instructions set, and mode (eg. arm/thumb)
>   --> gcc/configure --with-{arch,cpu,tune,mode}=foobar
> 
> - the correct ABI: EABI, OABI, iwmmxt
>   --> EABI/OABI: derived by gcc/configure from --target=...
>       arm*-{gnu,uclibc} is OABI, and arm*-{,uclibc}gnueabi is EABI.
>   --> iwmmxt: gcc/configure --with-abi=iwmmxt
> 
> - the correct endianness
>   --> derived by gcc/configure from --target=...
>       arm-* is little, while armeb-* is big
> 
> - and so on...
> 
> I don't know (yet!) of any such option that can't be selected at gcc's
> configure time.
> 
> So either we are (try to be) as exhautive as possible, or we rely as
> much as possible on the compiler to be correctly set up.
> 
> That's what I understood from Mike's post:
> http://lists.busybox.net/pipermail/uclibc/2009-April/042263.html
> quote
>   i dont think we should keep enabling lazy people.  either the right
>   options are selected by gcc in their toolchain, or they should manually
>   add the -mcpu or whatever flags to their extra cflags.  extending this
>   crap in our build system is a waste of time.
> /quote
> 
> Of course, I'm all for criticisms, and I built the patch just for that.
> 
> > > 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
> 
> Which would go in a header file, and be readily available to any file.
> 
> And from what I understand (but I may be wrong), you should *not* use BX
> if interworking is disabled. No interworking => do *not* switch back and
> forth between ARM and Thumb.
> 
> > > then we could get rid of the USE_BX build option completely.
> 
> That is the idea, but is not quite as simple as the two others were.
> 
> Regards,
> Yann E. MORIN.
> 

OK. I think the general direction is ok I believe. 
-- 
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/20090410/c8e44065/attachment.pgp>