------- Comment #1 from jakub at gcc dot gnu dot org 2010-06-25 13:10 -------
For DW_AT_low_pc, we do this because of (DWARF4, 3.1.1:
"A DW_AT_low_pc attribute may also be specified in combination with
DW_AT_ranges to specify the default base address for use in location lists (see
Section 2.6.2) and range lists (see Section 2.17.3)."
When the base address for use in location lists is 0, we can use absolute
addresses. This is used when not all code is in .text section.
/* We need to give .debug_loc and .debug_ranges an appropriate
"base address". Use zero so that these addresses become
absolute. Historically, we've emitted the unexpected
DW_AT_entry_pc instead of DW_AT_low_pc for this purpose.
Emit both to give time for other tools to adapt. */
add_AT_addr (comp_unit_die, DW_AT_low_pc, const0_rtx);
add_AT_addr (comp_unit_die, DW_AT_entry_pc, const0_rtx);
Perhaps for dwarf_version >= 4 or even just dwarf_version >= 3 we could avoid
emitting DW_AT_entry_pc.
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01709.html
So, from (a) IMHO only the point about DW_AT_entry_pc not allowed on CU is
valid.
(b) We emit DW_AT_ranges unless -gdwarf-2 -gstrict-dwarf, and that's IMHO the
right thing to do. If the prehistoric reader doesn't handle DW_AT_ranges, it
will ignore it, but not emitting ranges by default (remember upstream gcc still
defaults to -gdwarf-2) is a bad idea.
(c) The CU ranges are ranges of sections used. The padding is added there by
the linker, something the compiler has no control on.
(d) Again, the compiler can't guess that two different sections will be placed
consecutively. A post-linking (or during linking) DWARF compressor could
optimize this, sure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44664
