dwarf2 problem

Thu Jun 29 05:25:00 GMT 2000

(Note: I have sent a second version of this message with a uuencoded tarfile
attached, but it is well over 100k bytes in size.  This version does not
include the tarfile...)

I have generated a 2.95.2 cross-compiler using the following configure:

  configure \
    --target=m68k-elf \
    --with-cpu=m68000 \
    --disable-multilib \
    --with-dwarf2 \
    --with-gnu-as \
    --with-gnu-ld \
    --with-newlib \
    --prefix=$ENV \
    --enable-languages=c,c++

The compiler is generated on a PC running Redhat 6.2 Linux and generates
code, etc. for the 68000 as expected.   I have also generated GDB 5.0
as a remote-debugging platform:

--host=i686-pc-linux-gnu   --target=v68000

GDB version 5.0 (although I also get the same result using gdb-4.17)

I am trying to use GDB as a debugging tool for a synthesizable 68000 core
I have written.  The core has JTAG based debugging access...

I have written a target module (for GDB) which creates the JTAG cable
interface and seems to be working...  I have written functions to fetch
and store registers, memory, breakpoints, break, step, run, etc.

This all seems to function correctly... ie.  I can use the target command
to point GDB to the V68000 JTAG interface...  I can also use the load command
to "load obj_file_name" and the JTAG interface writes memory with the 
appropriate .text and .data sections...

The object files are created by gcc 2.95.2  configured as a cross-compiler.
I have targeted elf formatted object files...

The problem I am having is with the "file" command...

I am assuming that this command is a superset of the load command, meant to
send the .text and .data sections to the target, but also load the symbol
table and other debugging information into GDB for symbolic debugging...

The original C file is:

main() {
  printf("Hello World\n");
}

It is compiled using:

  m68k-elf-gcc -m68000 -gdwarf-2 -O2 -Tv68k.ld -o hello hello.c

When I type "file hello" 

(hello is a linked object file which prints "Hello World")

it returns:Reading symbols from hello... Dwarf Error: bad offset (0x1677c) in compilation unit header (offset 0x0 + 6).

It appears that GDB is having a problem reading the debugging info from the
object file...  I believe that it is all there... Using objdump to create
a list file shows the various sections, including the symbol table...

I've done a quick look through the code and don't know whether I should 
be trying to debug GDB or the object file...   Since objdump can read and
report the symbol table, etc. I'm assuming that the problem exists in
GDB...

I sent the "hello" object file, the hello.lst file, etc to Dave Anderson
who used his "dwarfdump" program to view the dwarf information included
in the object file....

His response is included here...

----- Begin Included Message -----

>From davea@quasar.engr.sgi.com@vlsi-concepts.com@vlsi-concepts.com Wed Jun 28 11:48:54 2000
>Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by vu-vlsi.ee.vill.edu (8.9.1/8.8.2) with ESMTP id LAA13424 for <hepler@vlsi-concepts.com>; Wed, 28 Jun 2000 11:25:31 -0400 (EDT)
Date: Wed, 28 Jun 2000 08:25:28 -0700 (PDT)
From: davea@quasar.engr.sgi.com@vlsi-concepts.com@vlsi-concepts.com (David B Anderson)
To: hepler@vlsi-concepts.com
Subject: dwarf 2

Ok. I got the file(s).

I ran some tests using the dwarfdump source (I built a
copy on a big-endian sgi machine).

I too get that error (the dwarfdump stuff handles 
endianness ok unless I have a bug somewhere).

Here are some lines from a window I was using to look
at stuff:

[4]    SHT_PROGBITS          0x18068    0xa060     0x28ac      .debug_abbrev
       0          0          0x1        0          0x00000000 

[5]    SHT_PROGBITS          0x1a914    0xc90c     0x18a17     .debug_info
       0          0          0x1        0          0x00000000 

[6]    SHT_PROGBITS          0x3332b    0x25323    0x93fa      .debug_line
       0          0          0x1        0          0x00000000 

[7]    SHT_PROGBITS          0x3c725    0x2e71d    0x921       .debug_pubnames
       0          0          0x1        0          0x00000000 

[8]    SHT_PROGBITS          0x3d046    0x2f03e    0x4e0       .debug_aranges
       0          0          0x1        0          0x00000000 

[irrelevant lines deleted]

proton 44% hxdump -s 0xc90c -l 100 hello
hxdump - Command not found
proton 45% rcp quasar.engr:/usr/people/davea/bin/hxdump ~/bin
proton 46% rehash
proton 47% hxdump -s 0xc90c -l 100 hello
   c90c 00000071 00020001 80680401 68656c6c  ...q.....h..hell
   c91c 6f2e6300 2f686f6d 652f6865 706c6572  o.c./home/hepler
   c92c 2f746573 74676363 00474e55 20432032  /testgcc.GNU C 2
   c93c 2e39352e 32203139 39393130 32342028  .95.2 19991024 (
   c94c 72656c65 61736529 00010001 00880001  release)........
   c95c 00a20003 332b0201 6d61696e 00010100  ....3+..main....

That info at 0xc90c
is the bits of .debug_info.

The dwarf spec says it starts with:
	4 byte unsigned integer of length of this compilation
	  unit header (x71 looks fine).
	2 byte version number (2 looks fine)
	4 byte unsigned offset into .debug_abbrev section
	  Oops. 

0001 8068  (little endian representation in hex)
is obviously not a valid offset into the .debug_abbrev section.

Looking at the .debug_abbrev with dwarfdump -b leads me to guess
that the compiler-authors emitted the offset as a *two* byte
unsigned int, as offset '1' into .debug_abbrev
is probably right. A bug in the compiler.

Makes one wonder how many places they made that mistake.
You could alter your copy of the libdwarf source to read
a 2 byte debug_info length.

This looks a lot like a compiler mistake.
Because it appears to be gcc, and gcc is known to emit
good dwarf2 on various platforms, this is some
platform-specific dwarf2-output-bug.

davea@sgi.com

----- End Included Message -----

He seems to think that GCC is creating a bad dwarf2 header for this
particular configuration...

A uuencoded, gzip'd, tarfile of some of the associated files is
included below...

Any help would be appreciated

Ed Hepler