[Bug debug/44664] New: CU DW_AT_low_pc, DW_AT_entry_pc are 0x0

[Bug debug/44664] New: CU DW_AT_low_pc, DW_AT_entry_pc are 0x0

[jan dot kratochvil at redhat dot com]

Unaware of any current (GDB) problems from it.

echo 'class C { public: C () {} }; int main() { C c; }' | g++ -Wall -g -x c++ -

FAIL g++ (GCC) 4.4.5 20100625 (prerelease)
FAIL g++ (GCC) 4.5.1 20100625 (prerelease)
FAIL g++ (GCC) 4.6.0 20100625 (experimental) [under the test below]

  Compilation Unit @ offset 0x0:
   Version:       2
 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    < c>   DW_AT_producer    : (indirect string, offset: 0x16): GNU C++ 4.6.0
20100625 (experimental)
    <10>   DW_AT_language    : 4        (C++)
    <15>   DW_AT_low_pc      : 0x0
    DW_AT_low_pc       DW_FORM_addr
    <1d>   DW_AT_entry_pc    : 0x0
    DW_AT_entry_pc     DW_FORM_addr
    <25>   DW_AT_ranges      : 0x0
    DW_AT_ranges       DW_FORM_data4
    <29>   DW_AT_stmt_list   : 0x0

Contents of the .debug_ranges section:
    Offset   Begin    End
    00000000 00000000004004b4 00000000004004cf
    00000000 00000000004004d0 00000000004004da
    00000000 <End of list>

  4004ce:       c3                      retq
  4004cf:       90                      nop
00000000004004d0 <_ZN1CC1Ev>:
  4004d0:       55                      push   %rbp

(a) DW_AT_low_pc and DW_AT_entry_pc are set to 0, this is incorrect.
 - this BZ
 DWARF4 does not define DW_TAG_compile_unit->DW_AT_entry_pc
 DWARF4 2.17 does not IMO define DW_AT_low_pc when DW_AT_ranges is present.

minor ones:
(b) DW_AT_ranges (which is DWARF3+) is used with DWARF version 2.  Consumer
    capable of only DWARF2 will most probably fail on such program.
(c) inter-function padding is excluded from DW_AT_ranges, does not it only
    needlessly increase the debug info size?
(d) In some cases there the .debug_info ranges are not merged (suboptimal
size).
    00000000 000000000040063c 000000000040066a
    00000000 000000000040066a 0000000000400690


-- 
           Summary: CU DW_AT_low_pc, DW_AT_entry_pc are 0x0
           Product: gcc
           Version: 4.4.5
            Status: UNCONFIRMED
          Severity: trivial
          Priority: P3
         Component: debug
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44664

[Bug debug/44664] CU DW_AT_low_pc, DW_AT_entry_pc are 0x0

[jakub at gcc dot gnu dot org]

------- 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