insight can't read my ELF file (target arm-unknown-elf)

insight can't read my ELF file (target arm-unknown-elf)

[Torsten Mohr]

Hi,

i have a small "hello world" project that i used
for an evaluation board with an ARM7 micro.

I always used that example with previous toolchains,
but now i get an error when i load the ELF in "insight":

Error loading "main.elf":
baad offset (0x20206a7) in compilation unit header \
(offset 0x0 + 6) [in module main.elf]

I don't really know what that means, "readelf -a" doesn't
complain.

I used:
binutils-2.14, 2.13.2
gcc-3.3.2
insight-6.0, 5.3.94

I've put the whole project (14k) here:

http://www.s.netic.de/tmohr/eb01a.tar.bz2


I don't really know if this is a problem of binutils,
but as linking was the latest step, i thought i'd ask
here first.

If i can give any more informations or can do any more
tests, please write me an email.


Thanks for any hints,
Torsten.

Re: insight can't read my ELF file (target arm-unknown-elf)

[Nick Clifton]

[-- Attachment #1: Type: text/plain, Size: 1490 bytes --]

Hi Torsten,

> I always used that example with previous toolchains,
> but now i get an error when i load the ELF in "insight":
>
> Error loading "main.elf":
> baad offset (0x20206a7) in compilation unit header \
> (offset 0x0 + 6) [in module main.elf]
>
> I don't really know what that means, "readelf -a" doesn't
> complain.

It wouldn't.  The problem is with the DWARF debug info, which "readelf
-a" does not display.  Try "readelf -w" to get this warning message:

  readelf: Warning: Unable to locate entry 1 in the abbreviation table

And if you look at the dump of the .debug.info section you will see:

  The section .debug_info contains:
  
    Compilation Unit @ 0:
     Length:        266
     Version:       2
     Abbrev Offset: 33687207
     Pointer Size:  4

The Abbrev Offset value is the culprit here.  It is definitely corrupt.

Further investigation leads me to discover that the problem appears to
be the custom linker script that you are using - it is putting the
debug sections into RAM at non-zero start addresses.  The linker
expects non-loadable sections (such as the .debug.* sections) to be
placed at address 0, and this is why you are getting corrupt debug
information.

It could be argued that this is a bug in the linker - it should not
make such an assumption, but there is a simple workaround - fix the
linker script.  I am attaching an updated version of your script which
produces a "main" executable which will load into GDB/Insight.

Cheers
        Nick


[-- Attachment #2: Linker script for eb01 application --]
[-- Type: application/octet-stream, Size: 1034 bytes --]

MEMORY
{
	ram : ORIGIN = 0x02020000, LENGTH = 0x40000
/*	ram : ORIGIN = 0x02020000, LENGTH = 0x10000 */
	rom : ORIGIN = 0x0,        LENGTH = 200M
}

SECTIONS
{
	.rodata : { *(.rodata) } >ram
	.text : { *(.text) } >ram
	.data : { *(.data) } >ram
	.bss : { *(.bss) } >ram
	.glue : { *(.glue) } >ram
	.glue_7 : { *(.glue) } >ram
	.glue_7t : { *(.glue) } >ram
	.stab : { *(.stab) } >rom
	.stabsrt : { *(.stabsrt) } >rom
	
	.debug          0 : { *(.debug) } >rom
	.line           0 : { *(.line) } >rom
	.debug_srcinfo  0 : { *(.debug_srcinfo) } >rom
	.debug_sfnames  0 : { *(.debug_sfnames) } >rom
	.debug_aranges  0 : { *(.debug_aranges) } >rom
	.debug_pubnames 0 : { *(.debug_pubnames) } >rom
	.debug_info     0 : { *(.debug_info) } >rom
	.debug_abbrev   0 : { *(.debug_abbrev) } >rom
	.debug_line     0 : { *(.debugline) } >rom
	.debug_frame    0 : { *(.debug_frame) } >rom
	.debug_str      0 : { *(.debug_str) } >rom
	.debug_loc      0 : { *(.debug_loc) } >rom
	.debug_macinfo  0 : { *(.debug_macinfo) } >rom
}

stackTop = 0x0202e000;