<div dir="ltr">So there have been several recent discussions about the issues around DWARF-agnostic linking and gc-sections, linkonce function definitions being dropped, etc - and just how much DWARF-awareness would be suitable in a linker to help with this situation.<br><br>I'd like to discuss a narrower instance of this issue: Zero length gc'd/deduplicated functions.<br><br>LLVM seems to at least produce zero length functions in a few cases:<br>* non-void function without a return statement<br>* function definition containing only llvm_unreachable<br>(both of these trap at -O0, but at higher optimization levels even the trap instruction is removed & you get the full power UB of control flowing off the end of the function into whatever other bytes are after that function)<br><br>So, for context, debug_ranges (this whole issue doesn't exist in DWARFv5, FWIW) is a list of address pairs, terminated by a pair of zeros.<br>With function sections, or even just with normal C++ inline functions, the CU will have a range entry for that function that consists of two relocations - to the start and end of the function. Generally the start of the function is the start of the section, and the end is "start of function + length of function (aka addend)".<br><br>Usually any relocation to the section would keep that section "alive" during linking - but that would cause debug info to defeat linker GC and deduplication. So there's special rules for how linkers handle these relocations in debug info to allow the sections to be dropped - what do you write in the bytes that requested the relocation?<br><br>Binutils ld: Special cases only debug_ranges, resolving all relocations to dead code to 1. In other debug sections, these values are all resolved to zero.<br>Gold and lld: Special cases all debug info sections - resolving all relocations to "addend" (so begin usually goes to zero, end goes to "size of function")<br><br>These special rules are designed to ensure omitted/gc'd/deduplicated functions don't cause the range list to terminate prematurely (which would happen if begin/end were both resolved to zero).<br><br><br>But with an empty function, gold and lld's strategy here fails to avoid terminating a range list by accident.<br><br>What should we do about it?<br><br>1) Ensure no zero-length functions exist? (doesn't address backwards compatibility/existing functions/other compilers)<br>2) adopt the binutils approach to this (at least in debug_ranges - maybe in all debug sections? (doing it in other sections could break )<br>3) Revisit the discussion about using an even more 'blessed' value, like int max-1? ( <a href="https://reviews.llvm.org/D59553" rel="noreferrer" target="_blank">https://reviews.llvm.org/D59553</a> )<br><br>(I don't have links to all the recent threads about this discussion - I think D59553 might've spawned a separate broader discussion/non-review - oh, Alexey wrote a good summary with links to other discussions here: <a href="http://lists.llvm.org/pipermail/llvm-dev/2019-September/135068.html">http://lists.llvm.org/pipermail/llvm-dev/2019-September/135068.html</a> )<br><br>Thoughts?<br><br></div>