[llvm-dev] DW_OP_implicit_pointer design/implementation in general

[Pavel Labath via llvm-dev]

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?

pl