confused with GCC 4.2.2

Do you use a arm-elf or arm-eabi build of the tools. Mind that the
latest test-version of WinARM still uses the prefix arm-elf but the
included tools are build with the arm-eabi. Please see
http://www.embedded.com/columns/technicalinsights/201000339?_requestid=621645
esp.  the lines at (29) in Listing 1.

Martin Thomas

Ok, I was copied the .ARM.exidx section into my linker script (that
based on your work :-) ). Now, the code has been compiled, but the code
length is zero :\

My linker script :


-----begin:


MEMORY
{
  CODE (rx) : ORIGIN = 0x00100000, LENGTH = 256k
  DATA (rw) : ORIGIN = 0x00200000, LENGTH = 48k
  STACK (rw) : ORIGIN = 0x0020c000,LENGTH = 16k
}

__FIRST_IN_RAM = ORIGIN(DATA);

/* Section Definitions */

SECTIONS
{
  /* first section is .text which is used for code */
  . = 0x0000000;

  .text :
  {
    KEEP(*(.vectorg))
    . = ALIGN(4);
    KEEP(*(.init))
    *(.text .text.*)                   /* remaining code */
    *(.gnu.linkonce.t.*)
    *(.glue_7)
    *(.glue_7t)
    *(.gcc_except_table)
    *(.rodata)                 /* read-only data (constants) */
    *(.rodata.*)
    *(.gnu.linkonce.r.*)
    . = ALIGN(4);
  } >CODE

  . = ALIGN(4);

  /* .ctors .dtors are used for c++ constructors/destructors */

  .ctors :
  {
    PROVIDE(_ctors_start_ = .);
    KEEP(*(SORT(.ctors.*)))
    KEEP(*(.ctors))
    PROVIDE(_ctors_end_ = .);
  } >CODE

  .dtors :
  {
    PROVIDE(_dtors_start_ = .);
    KEEP(*(SORT(.dtors.*)))
    KEEP(*(.dtors))
    PROVIDE(_dtors_end_ = .);
  } >CODE

      /* .ARM.exidx is sorted, so has to go in its own output section.
*/
    .ARM.exidx : {
        __exidx_start = .;
        *(.ARM.exidx* .gnu.linkonce.armexidx.*)
        __exidx_end = .;
    } >CODE

  . = ALIGN(4);

  _etext = . ;
  PROVIDE (etext = .);

  /* .data section which is used for initialized data */
  .data : AT (_etext)
  {
  _data = . ;
  KEEP(*(.vectmapped))
  . = ALIGN(4);
  *(.fastrun .fastrun.*)
  . = ALIGN(4);
  SORT(CONSTRUCTORS)
  . = ALIGN(4);
  *(.data)
  *(.data.*)
  *(.gnu.linkonce.d.*)
  . = ALIGN(4);
  } >DATA

  . = ALIGN(4);

  _edata = . ;
  PROVIDE (edata = .);

  /* .bss section which is used for uninitialized data */
  .bss :
  {
  __bss_start = . ;
  _bss_start_ = . ;
  *(.bss)
  *(.bss.*)
  *(.gnu.linkonce.b.*)
  *(COMMON)
  . = ALIGN(4);
  } >DATA
  . = ALIGN(4);
  _bss_end_ = . ;

  _end = .;
  PROVIDE (end = .);

  .int_data :
  {
    *(.internal_ram_top)
  } > STACK



  /* Stabs debugging sections.  */
  .stab          0 : { *(.stab) }
  .stabstr       0 : { *(.stabstr) }
  .stab.excl     0 : { *(.stab.excl) }
  .stab.exclstr  0 : { *(.stab.exclstr) }
  .stab.index    0 : { *(.stab.index) }
  .stab.indexstr 0 : { *(.stab.indexstr) }
  .comment       0 : { *(.comment) }
  /* DWARF debug sections.
   Symbols in the DWARF debugging sections are relative to the beginning
   of the section so we begin them at 0.  */
  /* DWARF 1 */
  .debug          0 : { *(.debug) }
  .line           0 : { *(.line) }
  /* GNU DWARF 1 extensions */
  .debug_srcinfo  0 : { *(.debug_srcinfo) }
  .debug_sfnames  0 : { *(.debug_sfnames) }
  /* DWARF 1.1 and DWARF 2 */
  .debug_aranges  0 : { *(.debug_aranges) }
  .debug_pubnames 0 : { *(.debug_pubnames) }
  /* DWARF 2 */
  .debug_info     0 : { *(.debug_info .gnu.linkonce.wi.*) }
  .debug_abbrev   0 : { *(.debug_abbrev) }
  .debug_line     0 : { *(.debug_line) }
  .debug_frame    0 : { *(.debug_frame) }
  .debug_str      0 : { *(.debug_str) }
  .debug_loc      0 : { *(.debug_loc) }
  .debug_macinfo  0 : { *(.debug_macinfo) }
  /* SGI/MIPS DWARF 2 extensions */
  .debug_weaknames 0 : { *(.debug_weaknames) }
  .debug_funcnames 0 : { *(.debug_funcnames) }
  .debug_typenames 0 : { *(.debug_typenames) }
  .debug_varnames  0 : { *(.debug_varnames) }

}


------end

Toth Jozsef wrote:
> Ok, I was copied the .ARM.exidx section into my linker script (that
> based on your work :-) ). Now, the code has been compiled, but the code
> length is zero :\

Try to add an ENTRY instruction to your linker-script. See line marked
with (3) in the mentioned listing.

Martin Thomas wrote:
> Toth Jozsef wrote:
>> Ok, I was copied the .ARM.exidx section into my linker script (that
>> based on your work :-) ). Now, the code has been compiled, but the code
>> length is zero :\
>
> Try to add an ENTRY instruction to your linker-script. See line marked
> with (3) in the mentioned listing.

yes, now works :blush: :-)

thank you

Tilo Lutz wrote:
> Martin Thomas wrote:
>> Do you use a arm-elf or arm-eabi build of the tools.
>
> Maybe a silly question but what is the difference.
> More detail: Why has it changed?

The "eabi" has been developed for binary compatibility. So you can use
for example a library ("lib-file") created with the Realview tools with
in a project which is developed with the arm-eabi GNU toolchain or IAR
EWARM 5.x and vice versa. A lot of information on the eabi can be found
on arm.com.

The current WinARM test-release (11/07) is a eabi-build which still uses
the arm-elf prefix to keep compatibility with older makefiles. It's just
for testing. My long-term plan (read: if I will ever have enough time)
is to modify and test all examples in the WinARM example-collection
for/with eabi so they can also be built with other precompiled arm-eabi
GNU toolchains like for example DevKitARM or Codesourcery's "G++ ARM
lite".

There are too many precompiled packages out there with small
differences. I think it's a good idea to get some common base so any
example created for a "bare metal" GNU ARM toolchain can be build with
any precompiled toolset. So it doesn't matter if the user has DevkitARM,
Sourcery G++, Idealist, Yagarto, GNUARM, Ride, Crossworks, WinARM or
whatever installed. I hope that the change to eabi is one step in this
direction.