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

[David Blaikie]

On Tue, Mar 9, 2021 at 3:40 PM Jakub Jelinek <jakub at redhat.com> wrote:

> On Tue, Mar 09, 2021 at 03:22:35PM -0800, David Blaikie wrote:
> > So, when the consumer evaluates DW_OP_GNU_parameter_ref, it handles it
> > > similarly to DW_OP_entry_value, unwinds to caller if it can identify
> it,
> > > and just looks up if some value is specified for it in that particular
> > > caller.
> > >
> >
> > Could you help me understand more how DW_OP_GNU_parameter_ref
> > works/differently from DW_OP_entry_value?
>
> DW_OP_entry_value refers to a register or memory in which a parameter
> is passed.

  When a parameter is not passed at all, there is no register or
> memory to which it can refer to.  So, DW_OP_GNU_parameter_ref instead
> refers to the DW_TAG_formal_parameter DIE and the consumer needs to find
> a DW_TAG_call_site_parameter that refers to the same DIE.
>

Ah, OK. Hmm - do you have different call_site_parameters for registers
versus parameters? Or I guess a call_site_parameter without a
DW_AT_location and only a DW_AT_call_value?

> > I think GCC doesn't do that, instead it would if considered beneficial
> > > copy the function to a non-exported one and optimize away the
> parameters in
> > > there (etc.).
> >
> >
> > Ah, OK - in which case there would be no DWARF for the copy? And the
> > original function would look as though it were "optimized away" (ie: not
> > have any DW_AT_low/high_pc, etc)?
>
> No, there is DWARF for the copy.  The original user function is the
> abstract
> origin and then it has two (or more) DW_TAG_subprogram DIEs that refer to
> that (and refer to DW_TAG_formal_parameter and DW_TAG_variable etc.) in it.
>

Hmm - is that "conforming" (I'm all for "DWARF provides some tools and
here's a way we can use them to describe this situation") DWARF? I would've
thought that there could only be one concrete instance of an abstract
definition.

And given that, could the user call this function from their debugger, and
how would the debugger get the ABI correct? (let's say there were no other
callers in other files - and we used gc-sections to optimize away that
original external copy, perhaps - if that makes a difference)

I guess since GCC didn't use the original symbol name, maybe the debugger
wouldn't consider the modified copy to be a valid target to call the
original function even though the DWARF says this is an instance of the
original function?

To come back to the original question - are there gaps between DWARF and
the ABI, I think the answer is yes (for internalized functions), certainly
for LLVM but I think for GCC too. At least in terms of what's
guaranteed/explicitly communicated - we might have to formalize some things
to make clear what conclusions can be reached when certain parameter
locations are used. As it is today, DWARF doesn't guarantee that the
DW_AT_location of a variable has no bearing on the way the function is
called - even a DW_AT_location that doesn't use a location list only has to
be valid after the prologue - so you can't guarantee that the location can
be used for the calling the function (the simplest example of this is at
-O0, you get nothing about how to call the function - but this DWARF would
be ambiguous with an optimized build that took the parameter from some
non-ABI register in the prologue and moved it into fbreg) - is that
correct? Have I misunderstood something?

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20210309/d484f875/attachment-0001.html>