A little more information: there seems to be a difference in the
resulting binary's floating point (which would go a long way to
explaining what I'm seeing). The ELF built with the more recent tools
results in this:
$ xscale-elf-readelf -h h.elf
ELF Header:
Magic: 7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: ARM
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0x80100000
Start of program headers: 52 (bytes into file)
Start of section headers: 448508 (bytes into file)
Flags: 0x602, has entry point, GNU
EABI, software FP, VFP
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 1
Size of section headers: 40 (bytes)
Number of section headers: 25
Section header string table index: 22
The ELF built with the older (faster) tools results in this:
$ arm-elf-readelf -h h.elf
ELF Header:
Magic: 7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: ARM
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0x80100000
Start of program headers: 52 (bytes into file)
Start of section headers: 411484 (bytes into file)
Flags: 0x402, has entry point, GNU
EABI, VFP
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 1
Size of section headers: 40 (bytes)
Number of section headers: 26
Section header string table index: 23
The relevant change is in the Flags: field. The new tools include
"software FP", the old tools don't.
Now, the processor doesn't have hardware floating point, yet the code
runs in both cases, so some kind of software floating point code is
being emitted.
TIA,
Rick
(original post below)
I've been building tools targeting the Marvell Xscale processor a
lot lately. A set of tools I build a few months ago seem to generate
much faster code on our target hardware than tools I built more
recently. There were some significant differences in the way the
tools were built, but it doesn't seem like that's enough to explain
the difference. Unfortunately, I don't remember exactly how I built
the older toolchain, so I'm hoping someone can help me determine
what it was by looking at the build result.
Old tools:
$ arm-elf-gcc -v
Using built-in specs.
Target: arm-elf
Configured with: ../configure --prefix=/usr/local/arm3 --target=arm-
elf --with-newlib --with-cpu=xscale --enable-languages=c,c++
Thread model: single
gcc version 4.2.1
$ arm-elf-ld --version
GNU ld (GNU Binutils) 2.18
How do I tell what version of newlib is installed (I think it's 1.15)?
Built using a multistep process, where I first built binutils, then
gcc, then newlib (I don't recall if I did a stage 1 GCC build first,
but somehow I got it all working).
The latest tools are slightly different, and built with a combined
tree build:
gcc-4.2.2
binutils-2.17
newlib-1.15
$ xscale-elf-gcc -v
Using built-in specs.
Target: xscale-elf
Configured with: ../combined/configure --target=xscale-elf --disable-
nls --with-newlib --prefix=/usr/local/gcc-xscale-elf --disable-
newlib-supplied-syscalls
Thread model: single
gcc version 4.2.2
I'm sorry I can't provide better information, but I'd really like to
figure this out. The code doesn't call into the standard C library,
but does make use of a lot of floating point code. Is it possible
that this code is better with the other tools (either built more
optimized, or generally different)? I don't know I'm just
speculating. It is C++ code (bouncing balls on a screen, the balls
are object instances).
Thanks for any help!
--
Rick
