arm-elf multilib issues

arm-elf multilib issues

[Joel Sherrill]

Hi,

I ran an experiment with arm-elf.  I took every
CPU model documented in the gcc.info file and
passed it in via -mcpu=XXX.  The following
CPU models linked successfully:

arm2 arm250 arm3 arm6 arm60 arm600 arm610 arm620 arm7 arm7m
arm7d arm7dm arm7di arm7dmi arm70 arm700 arm700i arm710
arm710c arm7100 arm720 arm7500 arm7500fe arm7tdmi arm7tdmi-s
arm710t arm720t arm740t strongarm strongarm110 strongarm1100
strongarm1110 arm8 arm810 arm9 arm920 arm920t arm922t arm940t
arm9tdmi

arm9e arm946e-s arm966e-s arm968e-s arm926ej-s arm10tdmi
arm1020t arm1026ej-s arm10e arm1020e arm1022e arm1136j-s
arm1136jf-s mpcore mpcorenovfp arm1156t2-s arm1176jz-s
arm1176jzf-s cortex-a8 cortex-a9 cortex-r4 cortex-r4f
cortex-m3 cortex-m1 xscale iwmmxt iwmmxt2 ep9312

The linker errors were similar for the failures.

 ../arm-elf/lib/libc.a(lib_a-fclose.o) does not use Maverick 
instructions, whereas a.out does
 ../arm-elf/lib/libc.a(lib_a-fclose.o) uses FPA instructions, whereas 
a.out does not
 ../arm-elf/lib/libc.a(lib_a-fclose.o) uses hardware FP, whereas a.out 
uses software FP

I notice that a lot of multilib options are
commented out in t-arm-elf. 

Do we want to enable more multilibs in arm-elf?
I am guessing based upon the messages that it will
require at least 3 more variants. 

Other architectures build more variants already so
it isn't that big a deal.

Thanks.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

Re: arm-elf multilib issues

[Paul Brook]

> Do we want to enable more multilibs in arm-elf?

Almost certainly not. As far as I'm concerned arm-elf is obsolete, and in 
maintenance only mode. You should be using arm-eabi.

IMHO building lots of multilibs by default significantly increases toolchain 
size and build time for little actual benefit. ARM CPUs are generally 
backwards compatible and we only have one important ABI variant, so very few 
multilibs are required for a functional toolchain. Anybody who cares about 
optimized runtime libraries probably wants tuning for their exact setup, 
rather than whatever arbitrary selections you're going to choose.

Paul

Re: arm-elf multilib issues

[Joel Sherrill]

Paul Brook wrote:
>> Do we want to enable more multilibs in arm-elf?
>>     
>
> Almost certainly not. As far as I'm concerned arm-elf is obsolete, and in 
> maintenance only mode. You should be using arm-eabi.
>
> IMHO building lots of multilibs by default significantly increases toolchain 
> size and build time for little actual benefit. ARM CPUs are generally 
> backwards compatible and we only have one important ABI variant, so very few 
> multilibs are required for a functional toolchain. Anybody who cares about 
> optimized runtime libraries probably wants tuning for their exact setup, 
> rather than whatever arbitrary selections you're going to choose.
>   

We only want to provide one arm-rtems toolset binary and  provide
the minimal number of multilibs to support as many ARMs
as possible.  So ultimately this will go in arm/t-rtems but I wanted
to see a non-OS target produce hello worlds that would run
with arm-XXX-run.  I will switch my testing to arm-eabi.  But
it uses the same t-arm-elf for variations.

Since this will be arm-rtems multilib's when submitted,
which variants and matches need to be added so we have
the right libraries for all CPU model arguments.  ld is
complaining at least about libc.a mismatches for these variations.

  does not use Maverick instructions, whereas a.out does
  uses FPA instructions, whereas a.out does not
  uses hardware FP, whereas a.out uses software FP

Suggestions welcomed.

I promise this is for arm-rtems. :)

--joel

Re: arm-elf multilib issues

[zoltan]

On Thu, 1 Oct 2009, Paul Brook wrote:

> > Do we want to enable more multilibs in arm-elf?
>
> Almost certainly not. As far as I'm concerned arm-elf is obsolete, and in
> maintenance only mode. You should be using arm-eabi.

I'm possibly (probably?) wrong, but as far as I know, it forces alignment
of 64-bit datum (namely, doubles and long longs) to 8 byte boundaries,
which does not make sense on small 32-bit cores with 32-bit buses and no
caches (e.g. practically all ARM7TDMI based chips). Memory is a scarce
resource on those and wasting bytes for alignment with no performance
benefit is something that makes arm-eabi less attractive. Also, as far as
I know passing such datums to functions might cause some headache due to
the 64-bit datums being even-register aligned when passing them to
functions, effectively forcing arguments to be passed on the stack
unnecessarily (memory access is rather expensive on a cache-less
ARM7TDMI). If you have to write assembly routines that take long long or
double arguments among other types, that forces you to shuffle registers
and fetch data from the stack. You lose code space, data space and CPU
cycles with absolutely nothing in return.

For resource constrained embedded systems built around one of those
32-bit cores arm-elf is actually rather more attractive than arm-eabi.

Zoltan

Re: arm-elf multilib issues

[Paul Brook]

> Since this will be arm-rtems multilib's when submitted,
> which variants and matches need to be added so we have
> the right libraries for all CPU model arguments.  ld is
> complaining at least about libc.a mismatches for these variations.
> 
>   does not use Maverick instructions, whereas a.out does
>   uses FPA instructions, whereas a.out does not
>   uses hardware FP, whereas a.out uses software FP

Either the errors are genuine, or your toolchain is misconfigured. It's common 
for old binutils to use different defaults to gcc.

Like I said before, switch to an EABI based toolchain and you shauldn't have 
any problems[1].  We have a proper object attribute system there, with 
corresponding directives for communication between compiler and assembler.

This can't be a new problem, and I have no sympathy for anyone inventing new 
code/targets that are not EABI based.

Paul

[1] Maverick support may be a bit busted because noone's bothered defining or 
implementing the appropriate EABI bits, but AFAICT the maverick code has 
always been fairly busted so you're not really loosing anything.

Re: arm-elf multilib issues

[Paul Brook]

> > Almost certainly not. As far as I'm concerned arm-elf is obsolete, and in
> > maintenance only mode. You should be using arm-eabi.
> 
> I'm possibly (probably?) wrong, but as far as I know, it forces alignment
> of 64-bit datum (namely, doubles and long longs) to 8 byte boundaries,
> which does not make sense on small 32-bit cores with 32-bit buses and no
> caches (e.g. practically all ARM7TDMI based chips). Memory is a scarce
> resource on those and wasting bytes for alignment with no performance
> benefit is something that makes arm-eabi less attractive. Also, as far as
> I know passing such datums to functions might cause some headache due to
> the 64-bit datums being even-register aligned when passing them to
> functions, effectively forcing arguments to be passed on the stack
> unnecessarily (memory access is rather expensive on a cache-less
> ARM7TDMI). If you have to write assembly routines that take long long or
> double arguments among other types, that forces you to shuffle registers
> and fetch data from the stack. You lose code space, data space and CPU
> cycles with absolutely nothing in return.

Meh. Badly written code on antique hardware.
I realise this sounds harsh, but in all seriousness if you take a bit of care 
(and common sense) you should get the alignment for free in pretty much all 
cases, and it can make a huge difference on ARMv5te cores.

If you're being really pedantic then old-abi targets tend to pad all 
structures to a word boundary. I'd expect this to have much more detrimental 
overall effect than alignment of doubleword quantities, which in my experience 
are pretty rare to start with.

Paul

Re: arm-elf multilib issues

[Alexandre Pereira Nunes]

On Thu, Oct 1, 2009 at 20:22, Paul Brook <paul@codesourcery.com> wrote:
>
> > > Almost certainly not. As far as I'm concerned arm-elf is obsolete, and in
> > > maintenance only mode. You should be using arm-eabi.

Is it now possible to build a 100% arm-eabi functional toolchain
(including i.e. newlib) in multilib mode straight from gnu sources?
Last time I tried, the only possibility was the codesourcery
toolchain, which receives no (public) frequent updates. Something has
changed since then?


> > I'm possibly (probably?) wrong, but as far as I know, it forces alignment
> > of 64-bit datum (namely, doubles and long longs) to 8 byte boundaries,
> > which does not make sense on small 32-bit cores with 32-bit buses and no
> > caches (e.g. practically all ARM7TDMI based chips). Memory is a scarce
> > resource on those and wasting bytes for alignment with no performance
> > benefit is something that makes arm-eabi less attractive. Also, as far as
> > I know passing such datums to functions might cause some headache due to
> > the 64-bit datums being even-register aligned when passing them to
> > functions, effectively forcing arguments to be passed on the stack
> > unnecessarily (memory access is rather expensive on a cache-less
> > ARM7TDMI). If you have to write assembly routines that take long long or
> > double arguments among other types, that forces you to shuffle registers
> > and fetch data from the stack. You lose code space, data space and CPU
> > cycles with absolutely nothing in return.
>
> Meh. Badly written code on antique hardware.
> I realise this sounds harsh, but in all seriousness if you take a bit of care
> (and common sense) you should get the alignment for free in pretty much all
> cases, and it can make a huge difference on ARMv5te cores.
>

I have to agree with Paul, at least partially. Except for a few bytes
wasted now and then regarding the parameter stacking misbehavior you
suggested, the other requirements never attempted to bite me. Not even
once. But I always had at least 2k of free ram to spare, to me that's
a lot :-)

Re: arm-elf multilib issues

[zoltan]

> Meh. Badly written code on antique hardware.
> I realise this sounds harsh, but in all seriousness if you take a bit of care

Yes, I think it does sound harsh, considering that, I believe, at least as
many chips are sold with ARM7TDMI core as the nice fat chips with MMU,
caches, 64 and 128 bit buses.

> (and common sense) you should get the alignment for free in pretty much all
> cases, and it can make a huge difference on ARMv5te cores.
> If you're being really pedantic then old-abi targets tend to pad all
> structures to a word boundary. I'd expect this to have much more
> detrimental overall effect than alignment of doubleword quantities,
> which in my experience are pretty rare to start with.

Well, I have to agree with the above.

Zoltan

Re: arm-elf multilib issues

[Samuel Tardieu]

>>>>> "Paul" == Paul Brook <paul@codesourcery.com> writes:

Paul> IMHO building lots of multilibs by default significantly increases
Paul> toolchain size and build time for little actual benefit. ARM CPUs
Paul> are generally backwards compatible and we only have one important
Paul> ABI variant, so very few multilibs are required for a functional
Paul> toolchain.

I have had problem in the past with Cortex M3 based processors because
libraries were not compiled with the Thumb-2 instruction set (which is
the only one supported by those ARM CPUs) variant.

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/