Re: Dwarf reader error from ld

[Eric DeVolder <devolder at evsx dot com>]

It now appears as if the Dwarf2 header is being emitted ( .8byte size, .2byte
version, .8byte abbrev offset, and .byte addr_size), but because of the 64b nature
of this arch, the 2.9.1 binutils I've been using doesn't recognize 8byte addresses
and thus takes offense.

I'm looking into updating to newer binutils. I examined binutils/bfd/dwarf2.c from
CVS and it clearly is a rewrite which supports 8byte addresses, among other things.

Eric

Eric DeVolder wrote:

> 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