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

[Mike Frysinger]

On Wednesday 08 April 2009 17:11:08 Yann E. MORIN wrote:
> On Wednesday 08 April 2009 01:45:57 Mike Frysinger wrote:
> > iirc, it is possible to build a toolchain that supports both big and
> > little endian simultaneously.  i believe the code sorcery guys do this. 
> > i would leave this option in for now until we can completely remove it
> > from the build system ...
>
> On one hand, either we fully trust the compiler, or we do not trust it at
> all.
>
> On the other hand, there are processors that can work in both endianness,
> even on the same board (eg. the Linksys NSLU2 is such a board that can be
> set to either endianness by software). Having a single, bi-endian compiler
> thus makes sense.
>
> I admit that keeping endianness as being selectable in menuconfig is not a
> bad idea per se, but we must be carefull at where we put the border line.

notice my emphasis with the endian stuff was it should all go or all stay.  i 
made no statement as to whether i thought it was a good idea in the first 
place.  but i dont really have a problem with these since there's only ever 
two choices :).

> As this patch is ARM-only, two questions about the ARM cleanup:
>
> First, I left the "Use BX" knob in place, because I do not fully understand
> all the implications it has. BX is an ARM insn that allows Branching and
> eXchange, that is conditionnally switch from ARM to Thumb (or the other way
> around) and branch to the specified offset or address. Can't we detect at
> compile time if both ARM and Thumb are available (*), and use BX if so, or
> just use MOV if not?

i'm not familiar enough with ARM to look into making its usage automatic, or 
whether it's even possible.

> Second, gcc defines the macro __ARM_EABI__ iff compiling for EABI. The only
> place where this is used is in libc/sysdeps/linux/arm/Makefile.arch
> Maybe we should have the mackefile check by itself. What do you think?

ABI's i have much less of a problem with having dedicated kconfig knobs for.  
unlike cpu variants, ABI's are petty slow moving targets and generally require 
explicit support in the C library before they can be supported.  in other 
words, since it isnt merely adding a new flag to the build flags to make it 
work, i think these can stay.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/uclibc/attachments/20090409/f72799e9/attachment.pgp>