[clang] [llvm] [clang][DebugInfo] Add virtual call-site target information in DWARF. (PR #167666)

[David Blaikie via llvm-commits]

dwblaikie wrote:

Sorry, yeah, I tihnk we did get a bit sidetracked/confused - maybe due to earlier descriptions, maybe due to being a bit context-free/looking only at an immediately preceding comment (in my case, i know I can have that problem - context switching between PRs/issues and not paging in the whole context again - sorry about that).

OK, so, sounds like we already do produce correct DWARF for an indirect call.

Problem is that DWARF isn't enough to identify ICF sites for indirect calls - because it doesn't record the originally intended destination of the call, only the actual call - so there's nothing to compare to to detect the difference.

I know this is way off in a different direction, but... 

Have you considered using a NOP-sled at the start of ICF'd functions (this would be a linker change - when ICF'ing, rather than resolving every address to the ICF'd version - resolve each unique original function to a unique NOP at the start of/before the start of the chosen preserved copy - that way each original function would still have a unique address at the call sites)? This would solve any cases of indirect calls, not just virtual ones, and would work in a debugger, would preserve uniqueness of addresses for C++ function address comparison semantics, etc.

But, that aside: I'd still argue that while a consumer aware of this approach could know which attribute (between DW_OP_call_target and DW_OP_call_origin) is authoritative, the spec doesn't really give them enough info to go on & a consumer ignorant of this handshake could pick somewhat arbitrarily between the two and get confused.

It seems like a misuse of DW_OP_call_origin & I think it'd be more suitable to use a distinct attribute for this since it has different semantics from the standard attribute.

(but, yeah, I'd consider NOP sleds as a more general solution - they have some code size impact, but maybe it's small enough to keep them even in fully optimized builds)

https://github.com/llvm/llvm-project/pull/167666