[Bug debug/109346] New: RFE add DW_AT_location to DW_TAG_subprogram

[Bug debug/109346] New: RFE add DW_AT_location to DW_TAG_subprogram

[woodard at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109346

            Bug ID: 109346
           Summary: RFE add DW_AT_location to DW_TAG_subprogram
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: woodard at redhat dot com
  Target Milestone: ---

There is a currently an issue filed against the DWARF5 standard that asks for
DW_AT_location to be the DW_TAG_subprogram and DW_TAG_inlined_subprogram.
https://dwarfstd.org/issues/221105.1.html At least for DW_TAG_subprogram the
issue seems to have fairly widespread support.

Due to the general permissiveness of the DWARF standard, I have found no place
in the DWARF5 standard where it says that you can't do this currently even
without a textual change in the future DWARF6 standard.

In addition to the reasons listed in the DWARF issue, there are a some
additional reasons to have it.

First of all there is DW_AT_GNU_vector. Because there is ambiguity in the
calling convention for array types vs vector types, DW_AT_GNU_vector is
required so that GDB can infer using the platform standard ABI where the return
value of a function would be located. This is discussed here:
https://lists.dwarfstd.org/pipermail/dwarf-discuss/2023-March/002212.html With
a location on a DW_AT_subprogram the needs of GDB could be met without
DW_AT_GNU_vector.

Furthermore, elfutils libdw has the following function which tries to find the
location of a function's return value.

/* Return location expression to find return value given a
   DW_TAG_subprogram, DW_TAG_subroutine_type, or similar DIE describing
   function itself (whose DW_AT_type attribute describes its return type).
   The given DIE must come from the given module.  Returns -1 for errors.
   Returns zero if the function has no return value (e.g. "void" in C).
   Otherwise, *LOCOPS gets a location expression to find the return value,
   and returns the number of operations in the expression.  The pointer is
   permanently allocated at least as long as the module is live.  */
extern int dwfl_module_return_value_location (Dwfl_Module *mod,
                                              Dwarf_Die *functypedie,
                                              const Dwarf_Op **locops);

This currently requires a libebl backend for the architecture that knows the
standard ABI for the particular return type. And it would indeed give the wrong
answer currently if the function doesn't follow the standard calling
convention.

The problem is with the increasing use of LTO, particularly within GNU/Linux
distros,the number of places where this function cannot correctly determine the
location of the return value is greatly increased. This is also true for static
functions, since programmers are being taught to be more careful with their
exported interfaces and they recognize the performance advantages given by
optimization passes that use a non-standard calling convention for static
functions the number of static functions is increasing.

The only really contested point of the proposal is what to do about
DW_TAG_inlined_subprogram. However, not adding DW_AT_location to
DW_TAG_inlined_subprogram would just be a quality of implementation issue and
so it could be omitted for the time being. How to add the location information
is not disputed but whether it would be possible for the compiler to correctly
emit it, and how much additional DWARF would be required to implement that
feature. It would end up being a huge location list for all the places where
the inlined subprogram is called. For the moment, I think everyone would be
happy if DW_AT_location were just applied to DW_TAG_subprogram and
DW_TAG_inlined_subprogram were skipped.