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 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
