Dwarf reader error from ld

[Eric DeVolder]

Ian Lance Taylor wrote:

>    Date: Wed, 12 Jan 2000 18:42:44 -0600
>    From: Eric DeVolder <devolder@evsx.com>
>
>    I'm porting binutils (and tweaking gcc) to a new 64bit architecture. I'm
>    getting the following error message from ld during linking when it
>    attempts to use a module in a library archive (libgcc.a in this case):
>
>    -------------------------------------
>    /usr/local/comp/e3/gcc/e3-elf/bin/ld: Dwarf Error: found dwarf version
>    '0' in compilation unit 'ta?}H
>                        Xs ', this reader only handles version 2
>    information.
>
> These errors are appearing when the linker tries to get line number
> information for an error report.

In following thru on your suggestion below, it really appears as if the 7 byte
header is missing (2byte ver, 4 byte abbrev table offset, 1 byte addr_size)
from the generated asm source. In looking at parse_comp_unit() in dwarf2.c, the
first thing it does is look for this header, and if it fails the sanity check,
it displays the error message above. (By the way, there is a code error here in
that the call to bfd_error_handler() is using the variable 'unit' before it is
assigned a value, thus the garbage printed for compilation unit in the above
error message.)

Dumping the .debug_info section confirms this theory:

Contents of section .debug_abbrev:
 0000 01110103 081b0825 08130b00 00022e00  .......%........
 0010 3f0c0308 3a0b3b05 11011201 400a0000  ?...:.;.....@...
 0020 00                                   .
Contents of section .debug_info:
 0000 92000000 00000000 02000000 00000000  ................
 0010 00000801 2e2e2f2e 2e2f6763 632f6763  ....../../gcc/gc
 0020 632f6c69 62676363 322e6300 2f757372  c/libgcc2.c./usr
 0030 2f6c6f63 616c2f64 65766f6c 6465722f  /local/devolder/
 0040 63726f73 73676363 2f6f626a 2d65332d  crossgcc/obj-e3-
 0050 656c662f 67636300 474e5520 4320322e  elf/gcc.GNU C 2.
 0060 39352e32 20313939 39313032 34202872  95.2 19991024 (r
 0070 656c6561 73652900 0102015f 5f6d756c  elease)....__mul
 0080 64693300 01250100 00000000 00000000  di3..%..........
 0090 00000000 00000001 5500               ........U.
Contents of section .debug_line:
Contents of section .debug_pubnames:
 0000 2b000000 00000000 02000000 00000000  +...............
 0010 00009a00 00000000 00007900 00000000  ..........y.....
 0020 00005f5f 6d756c64 69330000 00000000  ..__muldi3......
 0030 000000                               ...
Contents of section .debug_aranges:
 0000 38000000 00000000 02000000 00000000  8...............
 0010 00000800 04000000 00000000 00000000  ................
 0020 00000000 00000000 00000000 00000000  ................
 0030 00000000 00000000 00000000 00000000  ................

>From what I have learned, I would expect the first seven bytes of the
.debug_info section to contain:

0x02 0x00  (version, little endian)
0xXX 0xXX 0xXX 0xXX (abbrev table offset)
0x08 (addr size)

The first seven bytes clearly don't match this. In fact, the contents of the
.debug_info contain exactly what the asm source says:

    .section    .debug_info
    .8byte  0x92
    .2byte  0x2
    .8byte  $Ldebug_abbrev0
    .byte   0x8
    .byte   0x1
    .ascii "../../gcc/gcc/libgcc2.c\0"

    .ascii "/usr/local/devolder/crossgcc/obj-e3-elf/gcc\0"

    .ascii "GNU C 2.95.2 19991024 (release)\0"

    .byte   0x1
    .byte   0x2
    .byte   0x1
    .ascii "__muldi3\0"

    .byte   0x1
    .2byte  0x125
    .8byte  $LFB1
    .8byte  $LFE1
    .byte   0x1
    .byte   0x55
    .byte   0x0

So, I'm going to pursuit why the Dwarf header is being omitted. (I'm going to
start with the ASM_FILE_START macro in gcc).

>
>
>    libgcc1-test.o(.text+0xf8): undefined reference to `__divsi3'
>
> These errors mean that these symbols are not defined anywhere.  This
> has nothing to do with any DWARF issue.

yeah, i know...

>    As far as I can tell, the source file looks okay [snippet of gcc -S
>    below]. Admittedly, I'm not very familiar with Dwarf2, so i an be
>    thrashed if this is the problem...
>
> Do you override find_nearest_line in your BFD backend?  If you don't,
> the linker will think it should be reading 4 byte addresses from the
> DWARF debugging info.  You are giving it 8 byte addresses, so that
> won't work.  You can pass the last argument of
> _bfd_dwarf2_find_nearest_line as 8 to tell it to use 8 byte addresses.

No. I looked at this function, but there is no argument that says what addr
size is. Perhaps this is because I'm still on 2.9.1.

> I'm not sure why the DWARF information itself does not record this.

I think this is exactly the problem that I'm witnessing. Somehow gcc+dwarf
isn't emitting the header.

>    Because it is assembling ok, it appears as if binutils is correctly
>    handling Dwarf2 (ptr size is 8).
>
> This doesn't really prove anything.  The assembler does not parse the
> DWARF information at all.  It just writes it to the file.
>
> Ian

Thanks a bunch! I'll post an update of what I find.

Eric