[llvm-dev] DW_OP_implicit_pointer design/implementation in general

[Robinson, Paul via llvm-dev]

> -----Original Message-----
> From: Pavel Labath <pavel at labath.sk>
> Sent: Monday, November 18, 2019 5:08 AM
> To: David Blaikie <dblaikie at gmail.com>; Robinson, Paul
> <paul.robinson at sony.com>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>; AlokKumar.Sharma at amd.com
> Subject: Re: [llvm-dev] DW_OP_implicit_pointer design/implementation in
> general
> 
> On 15/11/2019 18:54, David Blaikie via llvm-dev wrote:
> >        You’d need such a DIE if you wanted the debugger to be able to
> >     look at the return value from source() anyway,
> >
> >
> > Not so far as I know - with GDB (& I assume LLDB) when you call a
> > function and return from it (eg: "finish" or "step" that steps across
> > the end of a function) the debugger prints out the return value (using
> > the DW_AT_type of the DW_TAG_subprogram that was executing & its
> > knowledge of the ABI to know where/how that value would be stored during
> > the return) & you can actually then query it and do other things using
> > the artificial variable name GDB provides
> 
> [Not really related to DW_OP_implicit_pointer, but I though this is
> worth mentioning.]
> 
> I'm not sure how gdb does this (though I don't know how it could do
> anything different), but the way this is implemented in lldb is a bit
> dodgy, and often does not work for non-trivial return types (== types
> that cannot be returned "by value" in registers).
> 
> The reason for that is that in these cases the ABI usually specifies
> that the address to store these return values is passed to the callee
> via some register. This register is usually also volatile, and the
> callee is free to reuse it for something else. That means that at the
> end of the "finish", in general, we're unable to know what the value of
> that register was at the *entry* to that function.
> 
> What lldb does right now is read the value of this register *after* the
> function returns, and hopes that it has not been modified. This works
> for simple leaf functions, but it can fail easily in more complex
> scenarios, particularly when optimizations are enabled.
> 
> Anyway, what I'm trying to say is that having a more trustworthy method
> of specifying the value/location of the function result would not be a
> completely bad idea. Or maybe there already is one and we're not using it?

I was imagining a more trustworthy method, although it's something that
DWARF does not currently specify.  Location of the return *address*, yes;
location of the return *value*, no (only its type).

Currently DWARF assumes the debugger is aware of the ABI used by the
platform and language; this was easy enough back in the days when return
values had simple types and usually one canonical register was enough.
Larger and more complicated return values probably deserve their own DIE,
with location info of some kind.
--paulr

> 
> pl