Compiling in pure Thumb2 mode

[Bernhard Reutner-Fischer]

On Fri, Jan 01, 2010 at 01:28:35PM +0100, Yann E. MORIN wrote:
>Hello All, and a happy new year!
>
>I just check the current git tree, and it does not seem possible to build in
>pure Thumb2 mode on a CPU that support ARM and Thumb2 modes (eg. Cortex-A8),
>while it seems possible to build for Thumb2-only CPUs (eg. Cortex-M3).
>Am I correct?
>
>On the same idea...
>Once upon a time (not so long ago...), there was the idea floating around [1]
>that uClibc should not care about the specifics of the target CPU, and should
>leave that to the compiler to decide. There even have been a mere attempt at
>doing so [2] [3], and even a consensus (at the time) [4] [5] but the code did
>not make it to the tree...
>
>What are your thoughts on the idea? I can tackle some patches for the archs
>I know of (ARM/MIPS/x86/x86_64) in the few following days...

I agree with Mike that it's cleaner to drop the mcpu/mtune stanza.

Let's just rely on the user to either pass correct UCLIBC_EXTRA_CFLAGS
or the user to have a proper toolchain that defaults to the desired
cpu/tune. In
http://repo.or.cz/w/buildroot.git/blob_plain/HEAD:/target/Config.in.arch
i have a table for arch/cpu(,subcpuseparator+subcpu)/tune that was current
for gcc-4.3.x. I'm sure you're aware that it is sometimes not
immediately obvious for people who don't know their target by heart to
properly setup their toolchain to default to their target and that
setting up defaults is/was sometimes not consistent across arches
(e.g. cris, who didn't used to have supported_defaults or bfin who can
have si-revisions in their --with-cpu) and may thus be hard for some to
do properly. Still, it's something the user should do, so yes let's
remove the tables. Can you provide an updated patch, please?
>
>Regards,
>Yann E. MORIN.
>
>[1] http://lists.uclibc.org/pipermail/uclibc/2009-April/042262.html
>      and subsequent post in the thread.
>[2] http://lists.uclibc.org/pipermail/uclibc/2009-April/042276.html
>[3] http://lists.uclibc.org/pipermail/uclibc/2009-April/042277.html
>[4] http://lists.uclibc.org/pipermail/uclibc/2009-April/042291.html
>[5] http://lists.uclibc.org/pipermail/uclibc/2009-April/042329.html