This is the mail archive of the
mailing list for the binutils project.
Re: Generate DW_AT_ranges for non-contiguous code
- From: Daniel Jacobowitz <drow at false dot org>
- To: Nick Clifton <nickc at redhat dot com>
- Cc: Sterling Augustine <sterling at tensilica dot com>, binutils at sourceware dot org
- Date: Mon, 7 Aug 2006 09:30:29 -0400
- Subject: Re: Generate DW_AT_ranges for non-contiguous code
- References: <44CE90B7.firstname.lastname@example.org> <44D71BFB.email@example.com>
On Mon, Aug 07, 2006 at 11:54:51AM +0100, Nick Clifton wrote:
> >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.
> 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.
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.