Re: arm-elf message

Re: arm-elf message

[Nick Clifton]

Hi Joel,

: I am using arm-rtems which is arm-elf aliased to arm-rtems for 
: both binutils and gdb.  When I try to load the resulting 
: executable in the simulator in gdb, I get an error message
: I assume is from the BFD.

Actually it is from gdb, specifically from
dwarf2_build_psymtabs_hard() in gdb/dwarf2read.c.

: Dwarf Error: bad offset (0xb91c0) in compilation unit header (offset
: 0x0 + 6).
:
: What does this message mean

I assume that you know what a compilation unit is.

It means that in the header describing the dwarf2 debug information
for a particular compilation unit, the offset into the .debug.abbrev
section is actually bigger than that section's size, (and hence must
be wrong/corrupt).

:  and more importantly what is broken?

Well it sounds like the compilation unit header is corrupt.  These
headers are usually the first data that occurs in the debugging
sections, so it is possible that the headers have been overwritten by
data from whichever section comes before the debug section ...

: I have forced some extra data in my .bss section and it turns out
: that 0xb91c0 is the _end of the entire program image.  

And by "forced" you mean what ?

This forcing, whatever it is, is probably the source of your
problems.  I would begin my investigation there.

Cheers
	Nick

Re: arm-elf message

[Joel Sherrill]

Nick Clifton wrote:
> 
> Hi Joel,
> 
> : I am using arm-rtems which is arm-elf aliased to arm-rtems for
> : both binutils and gdb.  When I try to load the resulting
> : executable in the simulator in gdb, I get an error message
> : I assume is from the BFD.
> 
> Actually it is from gdb, specifically from
> dwarf2_build_psymtabs_hard() in gdb/dwarf2read.c.
> 
> : Dwarf Error: bad offset (0xb91c0) in compilation unit header (offset
> : 0x0 + 6).
> :
> : What does this message mean
> 
> I assume that you know what a compilation unit is.
> 
> It means that in the header describing the dwarf2 debug information
> for a particular compilation unit, the offset into the .debug.abbrev
> section is actually bigger than that section's size, (and hence must
> be wrong/corrupt).

Weird.. I was using a handcrafted linker script and it did not
have this section in it.  That must have confused gdb. 

Fixed now.  Thanks.

> :  and more importantly what is broken?
> 
> Well it sounds like the compilation unit header is corrupt.  These
> headers are usually the first data that occurs in the debugging
> sections, so it is possible that the headers have been overwritten by
> data from whichever section comes before the debug section ...
> 
> : I have forced some extra data in my .bss section and it turns out
> : that 0xb91c0 is the _end of the entire program image.
> 
> And by "forced" you mean what ?
> 
> This forcing, whatever it is, is probably the source of your
> problems.  I would begin my investigation there.
> 
> Cheers
>         Nick

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

arm-elf message

[Joel Sherrill]

I am using arm-rtems which is arm-elf aliased to arm-rtems for
both binutils and gdb.  When I try to load the resulting 
executable in the simulator in gdb, I get an error message
I assume is from the BFD.  What does this message mean
and more importantly what is broken?

This GDB was configured as "--host=i686-pc-linux-gnu
--target=arm-rtems"...
Dwarf Error: bad offset (0xb91c0) in compilation unit header (offset 0x0
+ 6).

I have forced some extra data in my .bss section and it turns out that
0xb91c0 is the _end of the entire program image.  


  5 .bss          00091a50  00027770  00027770  0001f7d0  2**4
                  ALLOC

000b91c0 B _end

Thanks for any advice.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985