This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: DWARF2 and COFF?


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]