[lld] [ELF] Change .debug_names tombstone value to UINT32_MAX/UINT64_MAX (PR #74686)

[Fangrui Song via llvm-commits]

================
@@ -898,10 +898,16 @@ void InputSection::relocateNonAlloc(uint8_t *buf, ArrayRef<RelTy> rels) {
   const TargetInfo &target = *elf::target;
   const auto emachine = config->emachine;
   const bool isDebug = isDebugSection(*this);
-  const bool isDebugLocOrRanges =
-      isDebug && (name == ".debug_loc" || name == ".debug_ranges");
   const bool isDebugLine = isDebug && name == ".debug_line";
-  std::optional<uint64_t> tombstone;
+  std::optional<uint64_t> tombstone, debugTombstone;
----------------
MaskRay wrote:

Yes, the arch-neutral property has pros and cons.

I benchmarked this function with a similar one in mold. IIRC mold's is 2.x as fast as this lld implementation.

[template <class ELFT, class RelTy> InputSection::relocateNonAlloc](https://github.com/llvm/llvm-project/blob/5b7a7ec5a2106772de90a59c52e9fac7481f7e8a/lld/ELF/InputSection.cpp#L888) has performance 
problems:

* arch-specific checks in generic code: `R_386_GOTPC` workaround, x86 `R_SIZE`, RISC-V ADD/SUB relocations, (future) RISC-V ULEB128
* virtual function overhead (`X86, X86_64, ARM, AArch64`, etc : `TargetInfo`)
  + `addend += target.getImplicitAddend(bufLoc, type);`
  + `RelExpr expr = target.getRelExpr(type, sym, bufLoc);`
  + `target.relocateNoSym(bufLoc, type, SignExtend64<bits>(sym.getVA(addend)));`

I wanted to eliminate the overhead so I made [InputSection::relocateAlloc](https://github.com/llvm/llvm-project/commit/685b21255315e699aa839d93fe71b37d806c90c2) arch-specific but it's difficult to change `relocateNonAlloc` as `relocateNonAlloc` is a template (cannot be virtual).

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