This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


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

Re: dwarf 2.1 .debug_ranges


On Tue, Aug 07, 2001 at 07:23:52PM -0700, Michael Eager wrote:
> > What about the idea for using DW_FORM_block instead of .debug_ranges?
> > Surely debug size is still a consideration...
> 
> We hashed this back and forth.  I think that we went through several
> iterations on proposals before finally adopting the changes in 
> .debug_ranges.   Adding relocations was not seen as desirable.

What have relocations got to do with this?  Here I'm only talking
alternate representations of the same data.

At present we have

	.4byte  .debug_ranges+N		# DW_AT_ranges, DW_FORM_data4

	.8byte	<begin label 1> - <base addr>
	.8byte	<end label 1> - <base addr>
	.8byte	<begin label 2> - <base addr>
	.8byte	<end label 2> - <base addr>
	.8byte	0
	.8byte	0

This could just as easily be represented as

	.byte	32			# DW_AT_ranges, DW_FORM_block1
	.8byte	<begin label 1> - <base addr>
	.8byte	<end label 1> - <base addr>
	.8byte	<begin label 2> - <base addr>
	.8byte	<end label 2> - <base addr>

which saves 19 bytes of space.  We could save even more if we had
a way to inform that we don't need pointer-size bytes to represent
the displacements.

Obviously you can't usefully use base address selection entries
with this, but there are many cases in which they aren't needed.

Seems like it would take little effort for a debugger to get this
range information from either .debug_ranges or DW_FORM_block.


r~


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