We're converting an IAR project over to gnuarm (processor is
STR912FW44).  We've gotten most parts of the startup code converted in a
reasonable manner, but one anomaly remains.

In the IAR project, when we generate a listing from the ELF output, we
see at the beginning:

//*******************************************
ODU.elf:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 INTVEC,ICODE,CODE,INITTAB 000012ac  00000000  00000000  00000034
2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 DATA_Z        0000003a  04000000  04000000  000012e0  2**0
                  ALLOC

And the vector table begins at offset 0 in Idx0, which looks reasonable.
Note that Idx0 has "File offset" as 0.
However, when we build with gnuarm, we see:
//*******************************************

odu.elf:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .flashtext    00000050  00000000  00000000  00008000  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .text         0002c144  00000050  00000050  00008050  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE

The vector table still begins at offset 0 in Idx0, but notice that "File
offset" is 0x8000 ... Why is this happening??  It almost looks it's
mapped the secondary (boot) rom in front of the main 512K rom, but we
never told it to do that.  What causes this to occur???

Please show the linker-script.

Martin Thomas wrote:
> Please show the linker-script.

Oh, yes, sorry...

Dan Miller wrote:
> Martin Thomas wrote:
>> Please show the linker-script.
>
> Oh, yes, sorry...

Bump??

The only thing I need to understand here, is what defines that "file
offset" field, and what it actually means?

When I look at the .elf file (objdump -f odu.elf), it says:

odu.elf:     file format elf32-littlearm
architecture: arm, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x00000000

But I don't really think the cpu is starting at 0.  Also, if I load
the .elf file into arm-elf-insight, it starts at offset 0x1464C, which
is in the middle of main(), and doesn't correlate (as far as I can
detect) to any address, size, or offset anywhere in my code!?!?  I'm
very confused...

I currently can not help with "file offset".

Dan Miller wrote:
> The only thing I need to understand here, is what defines that "file
> offset" field, and what it actually means?
Can not help here. Never needed hat to work on this value.

>
> When I look at the .elf file (objdump -f odu.elf), it says:
>
> odu.elf:     file format elf32-littlearm
> architecture: arm, flags 0x00000112:
> EXEC_P, HAS_SYMS, D_PAGED
> start address 0x00000000
>
> But I don't really think the cpu is starting at 0.

I only know controllers where the start-addresse is fixed of can be
configured by hardware. You should find out at which addresse the
conroller starts and link at least the reset-vector to this address.
Don't know enough about STR9 to help.

> Also, if I load
> the .elf file into arm-elf-insight, it starts at offset 0x1464C, which
> is in the middle of main(), and doesn't correlate (as far as I can
> detect) to any address, size, or offset anywhere in my code!?!?  I'm
> very confused...

- First check the map-file for addresses of vectors, init-code, .text,
.data, .bss and maybe special sections. Are those addresses reasonable
is everything in the expected link-section?
- Check the symbol-file if symbols from linker and maybe from
startup-code are
set correctly
- Does a minimal applicaiton without interrupts work?
- Does a minimal applicaiton with interrupts-work?
- Is some kind of remapping used?