[lld] Fix lld crash wrt generated thunks growing away from the patched code (PR #170495)

[Tarcísio Fischer via llvm-commits]

================
@@ -597,7 +595,7 @@ AArch64Err843419Patcher::patchInputSectionDescription(
         uint64_t startAddr = isec->getVA(off);
         if (uint64_t patcheeOffset =
                 scanCortexA53Errata843419(isec, off, limit))
-          implementPatch(ctx, startAddr, patcheeOffset, isec, patches);
+          implementPatch(ctx, startAddr, patcheeOffset, isec, patches, dyn_cast<Symbol>(*codeSym));
----------------
tarcisiofischer wrote:

Thank you for the careful review!

Wouldn't it be the same to keep using the `sectionMap` but check if the symbol at hand is a mapping symbol? - I did implement your suggestion and the one I'm proposing, and it looks like both work for the current test cases, but would avoid adding another map, while still avoiding using mapping symbols, I believe:

```cpp
auto sectionSymbol = *codeSym;

/* if (isAArch64MappingSymbol(*sectionSymbol)) { */
if (sectionSymbol->getName() == "$x") {
  // It is an error for a relocation to reference a mapping symbol, so create one instead.
  sectionSymbol = addSyntheticLocal(ctx, "", STT_SECTION, 0, 0, *isec);
}
```

wyt?


> While I don't know of any code-generator that doesn't add a Section Symbol for each allocatable section, it is not required by the ELF specification. If sectionSymbolMap[isec] returns nullptr we can call addSyntheticLocal() with a symbol type of STT_SECTION, offset of 0, size 0, and the empty string "" as a name to generate one.

Regardless of the strategy, that case does happen in my new test, where there doesn't seem to find a symbol specifically for `Arch64AbsLongThunk` (This is not the same as the `_ret` one previously discussed). So the symbols currently named `__AArch64AbsLongThunk_$x` in my new test case will get "renamed" to just `__AArch64AbsLongThunk_` (but won't be a mapping symbol anymore).

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