This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: DWARF2 and COFF?
- To: binutils at sources dot redhat dot com
- Subject: Re: DWARF2 and COFF?
- From: "Mark E." <snowball3 at bigfoot dot com>
- Date: Sun, 3 Dec 2000 00:25:35 -0500
- References: <3A28C156.19040.367215@localhost> (snowball3@bigfoot.com)
> Supporting dwarf2 for COFF should work. The code in dwarf2.c should
> not be using elf_tdata. Instead, the address of the find_line_info
> struct should be passed in by the caller. See
> _bfd_stab_section_find_nearest_line for the right way to do it.
>
Thanks Ian, I've changed my local copy of dwarf2.c as suggested.
Unfortunately, I've run into another problem. It seems to be because of a
difference in how COFF and ELF handle relocations.
In my GCC generated assembly file, there is this snippet:
.section .debug_abbrev
Ldebug_abbrev0:
.section .text
Ltext0:
.section .debug_info
Ldebug_info0:
.section .debug_line
Ldebug_line0:
.section .text
Later on in this file, Ldebug_abbrev0 is referenced in .debug_info:
.section .debug_info
.long 0x1a5
.short 0x2
.long Ldebug_abbrev0
.byte 0x4
.byte 0x1
.ascii "c:/djgpp/projects/bfdsymify/debugtest.c\0"
...
read_abbrevs in bfd/dwarf2.c aborts because it doesn't like the value of
'.long Ldebug_abbrev0' apparently because its value has the .debug_abbrev
section's vma added to it. The error message is 'Dwarf Error: Abbrev offset
(x) bigger than abbrev size (y).' When I subtract the section's vma from the
offending offset, I get 0 which is probably what it's expecting.
I noticed that the way the .eh_frame section is generated by gcc prevents
this difference in representation from becoming a problem, so perhaps gcc
should be modified to use the same method used by .eh_frame to solve this
problem too.
Mark