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

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

[mark at gcc dot gnu.org]

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

Mark Wielaard <mark at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2012-05-01
                 CC|                            |mark at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #2 from Mark Wielaard <mark at gcc dot gnu.org> 2012-05-01 15:00:01 UTC ---
I think the DW_AT_entry_pc issue was resolved by:

commit cb18bd3ce42532858cc65a1f20f3d79d5c253dde
Author: mark <mark@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Fri Apr 1 18:24:52 2011 +0000

    Don't add DW_AT_low_pc if the CU has no associated code.

            * dwarf2out.c (dwarf2out_finish): Don't add low_pc and/or
            high_pc attribute if the CU has no associated code. Only output
            DW_AT_entry_pc for CU if not generating strict dwarf and
            dwarf_version < 4.

    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@171846
138bc75d-0d04-0410-96

Since comment #1 said "So, from (a) IMHO only the point about DW_AT_entry_pc
not allowed on CU is valid." Can this issue now be closed?

[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