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

[Nick Clifton]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: eb01.ld
Type: application/octet-stream
Size: 1034 bytes
Desc: Linker script for eb01 application
URL: <https://sourceware.org/pipermail/binutils/attachments/20031125/1a23b9bd/attachment.obj>