[Dwarf-Discuss] location-list ranges [Dwarf-Discuss Digest, Vol 34, Issue 2]

[Jakub Jelinek]

On Wed, Mar 24, 2010 at 12:43:11PM -0700, Bishop, John E wrote:
> First, the "full" info isn't that much larger than the "reduced" info.

Well, it is, at least for what GCC emits.
Here are some data on what the changes had on GCC compiler itself (cc1plus binary).
File sizes in bytes, section sizes in 6th column in hexadecimal, always the first
filesize + section sizes is for unmodified GCC (for optimized out variables the
compiler attempts to find where the value of that register would live at that PC range
or what value would it have, as long as it is expressible in DWARF4), the second
set of info is for the aggressive pruning of .debug_loc entries that are ouf of range -
if a var lives in some location at the end of some DW_AT_ranges range and also lives
at that spot at the start of the next range, .debug_loc uses just one range for that even
when the register/memory etc. is reused for something else in between, and the
third set of info is for the less aggressive pruning - what .debug_loc contains is
always valid for the ranges provided there, but the compiler doesn't bother emitting
location ranges that don't overlap with DW_AT_ranges at all:

i686 32-bit:
filesize: 65568300
  [28] .debug_info       PROGBITS        00000000 1002ada 139b6cd 00      0   0  1
  [33] .debug_loc        PROGBITS        00000000 2905694 f6b1b1 00      0   0  1
  [35] .debug_ranges     PROGBITS        00000000 39d3741 3c1400 00      0   0  1
filesize: 59548797
  [28] .debug_info       PROGBITS        00000000 1002ada 1397d82 00      0   0  1
  [33] .debug_loc        PROGBITS        00000000 2901ed0 9b0f44 00      0   0  1
  [35] .debug_ranges     PROGBITS        00000000 3415d10 3c1438 00      0   0  1
filesize: 61354047
  [28] .debug_info       PROGBITS        00000000 1002ada 1397ab8 00      0   0  1
  [33] .debug_loc        PROGBITS        00000000 2901b96 b69f17 00      0   0  1
  [35] .debug_ranges     PROGBITS        00000000 35ce9a9 3c12f0 00      0   0  1

x86-64 64-bit:
filesize: 86921679
  [28] .debug_info       PROGBITS        0000000000000000 10eb517 149eab7 00      0   0  1
  [32] .debug_loc        PROGBITS        0000000000000000 2a6ace7 1e300ab 00      0   0  1
  [34] .debug_ranges     PROGBITS        0000000000000000 49fcab8 7b8020 00      0   0  1
filesize: 75274552
  [28] .debug_info       PROGBITS        0000000000000000 10eb517 149af57 00      0   0  1
  [32] .debug_loc        PROGBITS        0000000000000000 2a672c4 1318257 00      0   0  1
  [34] .debug_ranges     PROGBITS        0000000000000000 3ee1241 7b7fa0 00      0   0  1
filesize: 78526419
  [28] .debug_info       PROGBITS        0000000000000000 10eb517 149aec3 00      0   0  1
  [32] .debug_loc        PROGBITS        0000000000000000 2a67268 163214f 00      0   0  1
  [34] .debug_ranges     PROGBITS        0000000000000000 41fb0dd 7b7f90 00      0   0  1

> Second, I'm not sure that a lexical scope is always required.  E.g., once
> there's a DW_TAG_subprogram entry, variables can "live" inside it without
> having a DW_TAG_lexical_block entry between the subprogram and the variable.

I wasn't talking about that case.  DIEs as children of DW_TAG_subprogram entry
are live through the whole function (well, DW_AT_ranges of the subprogram itself,
which except for splitting a function into multiple sections is usually consecutive).

	Jakub