[llvm-dev] DW_OP_implicit_pointer design/implementation in general
Pavel Labath via llvm-dev
llvm-dev at lists.llvm.org
Mon Nov 18 02:08:11 PST 2019
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
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?
More information about the llvm-dev