
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 14, 2020, at 2:21 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="">dblaikie@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hey folks,<br class=""><br class="">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.<br class=""><br class="">So picking up from some of the design discussion in <a href="https://reviews.llvm.org/D72489" class="">https://reviews.llvm.org/D72489</a>:<br class=""><br class=""><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class=""><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class="">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.</blockquote><br class="">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.</blockquote><br class="">OK, so a few questions on that: <br class="">1) Why would low_pc not be required for tail calls?<br class=""></div></div></blockquote><div><br class=""></div><div>I don’t think a meaningful return PC can be encoded at a tail call site. Control doesn’t transfer to `PC+4` past the jump instruction when the callee returns (the PC is set to whatever the last saved return address is instead).</div><div><br class=""></div><div>My understanding is that the point of AT_call_return_pc is to allow the debugger to present better backtraces, i.e. to implement a solver to figure out where to insert artificial tail call frames in the backtrace.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">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?<br class=""></div></div></blockquote><div><br class=""></div><div>I’m fuzzy on this but IIUC the low_pc attribute in a call site tag is the GNU predecessor to AT_call_return_pc. And a tag without return PC information just gives a hint to the debugger that the function contains a tail call.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">3) What features do these call_site tags enable (in the absence of call_site_parameters)?<br class=""></div></div></blockquote><div><br class=""></div><div>At the moment, just artificial tail call frames, but there are some interesting potential future applications. E.g.: disambiguating backtraces in the presence of function merging (a bigger deal for swift than it is for clang - the call site tag for a thunk-call could record the “original”/unmerged/source-level callee), and surfacing rich(er) information about CFI failures at call sites.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">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<br class=""></div></div></blockquote><div><br class=""></div><div>The goal is to describe all calls that aren’t optimized out. At least, I’m not sure that there’s a leaner subset that would really be sufficient for Apple’s use cases, and the size overhead hasn’t caused issues internally. We could certainly add a mode to clang to elide some of this call site info, though.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><br class="">(& 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?)<br class=""></div></div></blockquote><div><br class=""></div>Yep!<br class=""></div><div><br class=""></div><div>vedant</div><br class=""></body></html>