[llvm-dev] DebugInfo: Purpose of call site tags

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Tue Jan 14 14:21:38 PST 2020


Hey folks,

I'm trying to wrap my head around the implementation, purpose, and costs
involved in both the GCC-extension v4 and standard v5 DW_TAG_call_site,
call site parameters, addresses, etc.

So picking up from some of the design discussion in
https://reviews.llvm.org/D72489:

Me (Blaikie): I'm not sure why AT_call_return_pc would be needed at a tail
call site as the debugger must ignore it. As for emitting DW_AT_low_pc
under gdb tuning, I think this might be an artifact from the original GNU
implementation.


Djordje: Yes, that is the GNU implementation's heritage (I cannot remember
why GCC generated the low_pc info in the case of the tail calls), but GNU
GDB needs the low_pc (as an address) in order to handle the call_site and
call_site_parameters debug info for non-tail calls. To avoiding the pc
address info in the case of tail calls makes sense to me, since debuggers
should avoid that info.


OK, so a few questions on that:
1) Why would low_pc not be required for tail calls?
2) Why is the v4 low_pc predicated on GDB tuning too? If we're producing
the call_site tag, what's the point of that without an address?
3) What features do these call_site tags enable (in the absence of
call_site_parameters)?
4) What's the end goal in terms of what calls should be described in the
DWARF? (describing literally every call sounds /super/ expensive) - they
currently seem quite different between GCC and Clang on a few test cases
I've tried, so it's hard to tell the logic

(& if I understand correctly, the call_site_parameters are intended to work
collaboratively between callees and callers, so if, say, a parameter value
is caller saved & then clobbered in the callee - you could still print the
value of that parameter by looking at the saved copy in the caller?)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200114/fc85078f/attachment.html>


More information about the llvm-dev mailing list