[lld] Use -1 as tombstone value for discarded code ranges

[Eric]

Summary

Under existing behavior discarded functions are relocated to have the start pc 0. This causes problems when debugging as they typically overlap the first function and lldb symbol resolution frequently chooses a discarded function instead of the correct one. Using the value -1 or -2 (depending on which DWARF section we are writing) is sufficient to prevent lldb from resolving to these symbols.

[sbc100]

Are there no tests that fail under this change? If not, I guess we should add one.

[MaskRay]

In D91803#2405939, @sbc100 wrote:

Are there no tests that fail under this change? If not, I guess we should add one.

Failed Tests (3):
  lld :: wasm/debug-removed-fn.ll
  lld :: wasm/debuginfo.test
  lld :: wasm/undefined-weak-call.ll

The change does not seem right. For non-debug sections (when --allow-undefined is set), addend; .debug_ranges/.debug_loc => -2; other .debug_* => -1

[dblaikie]

In D91803#2405969, @MaskRay wrote:

In D91803#2405939, @sbc100 wrote:

Are there no tests that fail under this change? If not, I guess we should add one.

Failed Tests (3):
  lld :: wasm/debug-removed-fn.ll
  lld :: wasm/debuginfo.test
  lld :: wasm/undefined-weak-call.ll

The change does not seem right. For non-debug sections (when --allow-undefined is set), addend; .debug_ranges/.debug_loc => -2; other .debug_* => -1

+1 to that. Could also use a test case for this new functionality.

[Eric]

Hope this looks better!

[sbc100]

lgtm!.. I'll leave the final approval to @yurydelendik

lld/wasm/InputChunks.cpp

408

Maybe a comment here explaining why we do this?

lld/wasm/InputChunks.h

230

We use the lowerCamel style so I think this should be tombstoneValue?

lld/wasm/InputFiles.cpp

196

So setting the tombstone to zero means we should include the Addend ?

lld/wasm/InputFiles.h

106

It seems like all of the callsites should probably include the tombstone no?

Perhaps remove the default and specify it at each call site?

[MaskRay]

lld/wasm/InputChunks.h

230

Is the space consumption a concern?

[sbc100]

lld/wasm/InputChunks.h

230

I not been to concerted about adding data O(input chunk). Honestly, we have not done much in the way optimizing wasm-ld for speed or memory consumption. Rui often guided me to keep the symbol size down and to avoid per-symbol hash lookup.. but per-input-chunk data I've not been too concerned about.

I guess one alternative would be to store a tombstone-type enum with three possible values?

[dblaikie]

lld/test/wasm/debug-removed-fn.ll

7

This looks suspcious - is something in the implementation (or the dumper) truncating the 64 bit -1 to a 32 bit -1? Or is this a bug in the dumper that it's printing out a 32bit value as a 64 bit value?

lld/wasm/InputChunks.cpp

411–417

Avoid "else after return" per the LLVM style guide. Also nice to reduce nesting, so I'd probably go with something like:

if (!.debug_)
  return 0;
if (.debug_ranges || .debug_loc)
  return -2
return -1

lld/wasm/InputFiles.cpp

196

Yeah, I guess that's beyond my debug info purview - but I'd suggest checking what bfd ld does here & maybe going with that, rather than what gold does/lld used to do. Which is probably absolute 0 rather than addend. For broader compatibility (& probably make this code a bit less subtle - avoiding the tombstone of zero not really being zero)

[MaskRay]

lld/wasm/InputChunks.h

230

The sizes of SymbolUnion and InputSections are important for the ELF's port.

As an example, the basic block sections feature cost us more than 1% peak memory usage. D91018 claimed back 0.6%

[sbc100]

lld/wasm/InputChunks.h

230

Point taken. And since wasm mandates -ffunction-sections and -fdata-sections is the default we are even more effected than ELF by default I guess.

I'm embarrassed to say I have done zero benchmarking of wasm-ld thus far.

[Eric]

lld/test/wasm/debug-removed-fn.ll

7

Looks like this file is coming from a R_WASM_FUNCTION_OFFSET_I32 type relocation so this is being written as 32 bits. I assume the dumper casts to 64 bits whether it read a 32 or 64 bit address.

lld/wasm/InputChunks.h

230

Note that this is not in InputChunk, it is in InputSection, so this is once per custom wasm section, of which there might be what, a dozen? I could get rid of it but then we would need to do 1-3 string comparisons against the section name for every relocation in that section, which I was concerned could be costly, though I also have done no wasm-ld benchmarking.

I actually considered putting it in InputChunk so as to avoid lots of virtual function calls. If I did that this would cost us a megabyte for especially large applications.

lld/wasm/InputFiles.cpp

196

Yes, this was based on MaskRay@'s comment on my initial commit. If there is not agreement on this perhaps bring discussion back to the email thread?

lld/wasm/InputFiles.h

106

This felt different to me because zero has a unique meaning, it is not used as a tombstone it means we don't do tombstoning. I don't think adding ", 0" to the other callsites would make the code any clearer but of course I can do that if there is a strong preference for it.

[Eric]

lld/test/wasm/debug-removed-fn.ll

7

It turns out if I update my llvm repo to include your tombstone handling code in llvm-dwarfdump, this line disappears.

[sbc100]

There are 4 callers of calcNewValue():

InputChunk::writeTo
InputFunction::calculateSize
InputFunction::writeTo
InputSegment::generateRelocationCode

It seems that they should all be consistent in passing getTombstone() as the second argument. It doesn't make sense that different callsites would get a different new value for a given relocation. They all logically want to get the same answer I believe.

[Eric]

Okay, I've changed it to call getTombstone everywhere.

[dblaikie]

lld/wasm/InputFiles.cpp

196

Ah, this one?

The change does not seem right. For non-debug sections (when --allow-undefined is set), addend; .debug_ranges/.debug_loc => -2; other .debug_* => -1

@MaskRay is that what ld.bfd does? ("addend" for non-debug sections)

[MaskRay]

lld/wasm/InputChunks.cpp

298

For all these file->calcNewValue(rel, getTombstone()) calls, shouldn't getTombstone() cached to avoid performance overhead?

lld/wasm/InputFiles.cpp

196

Yes for "addend" for non-debug sections. This makes subtraction work.

[dblaikie]

lld/wasm/InputFiles.cpp

196

Ah, fair enough - thanks for the context!

[Eric]

Hope everyone had a nice Thanksgiving break! Are any further changes necessary here?

[MaskRay]

Looks great! Please include diff context in future patches (https://llvm.org/docs/GettingStarted.html#sending-patches)

lld/wasm/InputChunks.cpp

435

-2l is correct but is not an appropriate literal suffix. UINT64_C(-2) can be used.

lld/wasm/InputFiles.cpp

216

Delete braces

https://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements

lld/test/wasm/debug-removed-fn.ll

 
 ; CHECK: Address
 ; CHECK: 0x0000000000000005
-; CHECK: 0x0000000000000000
+; CHECK: 0x00000000ffffffff
 
 ; CHECK: .debug_ranges contents:
 ; CHECK: 00000000 {{[0-9]+}} {{[0-9]+}}
-; CHECK: 00000000 {{[0-9]+}} {{[0-9]+}}
+; CHECK: 00000000 fffffffe fffffffe
 ; CHECK: 00000000 <End of list>
 
 ; ModuleID = 't.bc'

lld/test/wasm/debuginfo.test

 CHECK-NEXT:                DW_AT_external      (true)
 CHECK-NEXT:                DW_AT_decl_file     ("{{.*}}hi_foo.c")
 CHECK-NEXT:                DW_AT_decl_line     (8)
-CHECK-NEXT:                DW_AT_location      (DW_OP_addr 0x0)
+CHECK-NEXT:                DW_AT_location      (DW_OP_addr 0xffffffff)
 
 CHECK:   DW_TAG_subprogram
 CHECK-NEXT:                DW_AT_low_pc

lld/wasm/InputChunks.h

       : file(f), live(!config->gcSections), discarded(false), sectionKind(k) {}
   virtual ~InputChunk() = default;
   virtual ArrayRef<uint8_t> data() const = 0;
+  virtual uint64_t getTombstone() const { return 0; }
 
   // Verifies the existing data at relocation targets matches our expectations.
   // This is performed only debug builds as an extra sanity check.

 class InputSection : public InputChunk {
 public:
   InputSection(const WasmSection &s, ObjFile *f)
-      : InputChunk(f, InputChunk::Section), section(s) {
+      : InputChunk(f, InputChunk::Section), section(s), tombstone_value(getTombstoneForSection(s.Name)) {
     assert(section.Type == llvm::wasm::WASM_SEC_CUSTOM);
   }
 

   // Offset within the input section.  This is only zero since this chunk
   // type represents an entire input section, not part of one.
   uint32_t getInputSectionOffset() const override { return 0; }
+  uint64_t getTombstone() const override { return tombstone_value; }
+  static uint64_t getTombstoneForSection(StringRef name);
 
   const WasmSection &section;
+  const uint64_t tombstone_value;
 };
 
 } // namespace wasm

lld/wasm/InputChunks.cpp

 
   for (const WasmRelocation &rel : relocations) {
     uint8_t *loc = buf + rel.Offset + off;
-    auto value = file->calcNewValue(rel);
+    auto value = file->calcNewValue(rel, getTombstone());
     LLVM_DEBUG(dbgs() << "apply reloc: type=" << relocTypeToString(rel.Type));
     if (rel.Type != R_WASM_TYPE_INDEX_LEB)
       LLVM_DEBUG(dbgs() << " sym=" << file->getSymbols()[rel.Index]->getName());

   }
 }
 
+uint64_t InputSection::getTombstoneForSection(StringRef name) {
+  if (name.startswith(".debug_")) {
+    if (name.equals(".debug_ranges") || name.equals(".debug_loc")) {
+      return -2;
+    } else {
+      return -1;
+    }
+  } else {
+    return 0;
+  }
+}
+
 } // namespace wasm
 } // namespace lld

lld/wasm/InputFiles.h

   void dumpInfo() const;
 
   uint32_t calcNewIndex(const WasmRelocation &reloc) const;
-  uint64_t calcNewValue(const WasmRelocation &reloc) const;
+  uint64_t calcNewValue(const WasmRelocation &reloc, uint64_t tombstone = 0) const;
   uint64_t calcNewAddend(const WasmRelocation &reloc) const;
   uint64_t calcExpectedValue(const WasmRelocation &reloc) const;
   Symbol *getSymbol(const WasmRelocation &reloc) const {

lld/wasm/InputFiles.cpp

 }
 
 // Translate from the relocation's index into the final linked output value.
-uint64_t ObjFile::calcNewValue(const WasmRelocation &reloc) const {
+uint64_t ObjFile::calcNewValue(const WasmRelocation &reloc, uint64_t tombstone) const {
   const Symbol* sym = nullptr;
   if (reloc.Type != R_WASM_TYPE_INDEX_LEB) {
     sym = symbols[reloc.Index];
 
     // We can end up with relocations against non-live symbols.  For example
-    // in debug sections. We return reloc.Addend because always returning zero
-    // causes the generation of spurious range-list terminators in the
-    // .debug_ranges section.
-    if ((isa<FunctionSymbol>(sym) || isa<DataSymbol>(sym)) && !sym->isLive())
-      return reloc.Addend;
+    // in debug sections. We return a tombstone value in debug symbol sections
+    // so this will not produce a valid range conflicting with ranges of actual
+    // code. In other sections we return reloc.Addend.
+
+    if ((isa<FunctionSymbol>(sym) || isa<DataSymbol>(sym)) && !sym->isLive()) {
+      return tombstone ? tombstone : reloc.Addend;
+    }
   }
 
   switch (reloc.Type) {