This is the mail archive of the crossgcc@sourceware.cygnus.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more infromation.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Linking of ARM-elf object files


Nick Clifton wrote:
> 
> : Trying again, now the binutils-20000116, for arm-elf showed that the
> : linker still doesn't produce executables which could run under GDB
> : and the simulator...
> 
> Can you explain further about what is going wrong here ?

 When using a C-library and a libgcc.a, which were produced using the 'old'
binutils, and trying now to use the 'new' binutils, the generated executables
will not run under the arm-simulator ('arm-elf-run') or GDB... The simulator
just starts the program and exits silently, no errors or any output from the
program. GDB behaves quite the same way --- one can single-step the program,
but nothing goes to stdout from the program...

 Those who have built the arm-elf toolset from the eCos-1.2.1-tools sources
(990321), or used binutils-snapshots from last spring will have this problem,
if not using the new binutils while updating GCC and not updating the C-library
using the new binutils...

> :  My test executables will become about two times bigger than those
> : produced with a working linker (990426)
> 
> Hmm, Have you determined what is getting bigger ?  Is it the code, the
> debug information or something else ?

 I meaned the 'size' seen with 'ls -l', here is a chart about the versions
used for the examples :

  Name                    GCC-version     binutils        newlib
  --------------------------------------------------------------
  tst_arm-elf-b1.x        egcs-20000110   990426          1.8.0
  tst_arm-elf-b.x         egcs-20000110   000116          1.8.2

 Executable sizes for a printf()-test program with 'ls -l' :

  -rwxr-xr-x   1 kai      users       80063 Jan 18 17:02 tst_arm-elf-b.x*
  -rwxr-xr-x   1 kai      users       39917 Jan 17 17:30 tst_arm-elf-b1.x*

 The code and data sizes are now also somehow bigger:

     text    data     bss     dec     hex filename
    36616    2248     188   39052    988c tst_arm-elf-b.x
    31584     896      12   32492    7eec tst_arm-elf-b1.x

> In order to fix this, we had to change the linker and also change the
> relocs being produced by the assembler, which made binaries produced
> by the fixed toolchain incompatible with binaries produced by the old
> toolchain.  Since people were (and are) still using the old toolchain
> we could not just arbitrarily switch over to the new relocs without
> proving some form of backward compatability.
> 
> We provided this compatability in two ways.  The first was code in BFD
> to automatically detect binaries produced by the fixed toolchain and
> so behave correctly.  (See the comment in bfd/elf32-arm.h starting at
> line 1225).  This code relies upon using the OSABI field of the ELF
> e_ident[] array to detect old binaries (value = 0) and new binaries
> (value = 0x61).

 I saw it better to rebuild my C-library for arm-elf, using the new
binutils. When the libs were updated, the binaries now run ok under
the simulator. The bigger code size in the example may be the result
of printf() now being bigger in newlib-1.8.2 than in the old 1.8.0.
I saw the egcs-20000110 producing smaller code than gcc-2.95.x (which
was used to compile newlib-1.8.0), so there must be some sane
explanation...

 Thanks for your answers!

 Cheers,  Kai



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]