[Dwarf-Discuss] compilers generating ABI non-compliant function calls?

[Andrew Cagney]

On Tue, 9 Mar 2021 at 10:13, Frank Ch. Eigler <fche at redhat.com> wrote:
>
> Hi, Andrew -
>
> On Tue, Mar 09, 2021 at 10:05:04AM -0500, Andrew Cagney via Dwarf-Discuss wrote:
> > [...]
> > This means that:
> > - for simple objects, local functions; and
> > - with link-time-optimization, everything except library interface functions
> > are fair game for ABI non-compliant call optimizations.
> >
> > Is anyone aware of a compiler doing this (I figure with LTO there's a
> > strong incentive)?  And if so, how is this described to the debugger.
> > The ABI / calling-convention is no longer on hand for filling in the
> > blanks.
>
> FWIW, gcc does not leave ABI-dependent gaps in the DWARF generated for
> function parameters.  First class location lists are given, whether or
> not they are in the ABI-governed locations, or whether they've been
> moved somewhere else, or whether they've been optimized out so that a
> consumer must recompute it somehow, or whether they exist at all.

So for instance, given a 64-bit big-endian ABI that left-packs large
structs vis:

struct {
   uint64_t register_three;
   uint8_t left_side_of_register_four;
};

but decides to pass left_side_of_register_four on the RHS would
generate a DW_OP_bit_piece DW_OP_piece (implied LHS).

> As I understand it, the location of *function return values* is
> however a gap in DWARF, and a consumer tool must resort to ABI specs.
> (Thus the elfutils dwfl_module_return_value_location() function.)  I'm
> sure there's a Reason for this, but having worked on a consumer, it'd
> be handy if DWARF did explicitly identify the return value location
> too.
>
> - FChE
>