This is the mail archive of the
mailing list for the binutils project.
Re: Generate DW_AT_ranges for non-contiguous code
- From: Nick Clifton <nickc at redhat dot com>
- To: Nick Clifton <nickc at redhat dot com>, Sterling Augustine <sterling at tensilica dot com>, binutils at sourceware dot org
- Date: Mon, 07 Aug 2006 15:08:13 +0100
- Subject: Re: Generate DW_AT_ranges for non-contiguous code
- References: <44CE90B7.email@example.com> <44D71BFB.firstname.lastname@example.org> <20060807133029.GA15001@nevyn.them.org>
Hmm, have you tried bumping the version number and seeing how it affects
GDB ? I am thinking that maybe it is the right thing to do, although it
may be necessary to add another GAS command line switch to disable the
generation of DWARF3 specific debug info for environments with debuggers
that cannot handle it.
One issue here is that this particular usage of DW_AT_ranges is dwarf 3,
and gas emits 2 for the dwarf version number. Don't know the right thing
to do there. Bumping the version number for this seems extreme.
Sterling is actually correct; you shouldn't bump the version number for
this. Every major revision of the DWARF standard which includes a
version number bump also includes some incompatible format changes
(i.e. a situation where you need to know which version it is, in order
to parse it correctly). From .debug_info version 2 to .debug_info
version 3 there were only tiny changes; one was the size of an address
versus the size indicated in the dwarf header, and another was the use
of a LEB128 versus a byte.
If you are only adding new attributes or tags from dwarf3, version 2
consumers will generally handle it correctly.
Ok thanks - in which case the patch looks good, but I would like
Sterling to confirm that it actually fixes the problem since it did not
appear to do so for me.