[lld] [ELF] Merge verdefIndex into versionId. NFC (PR #72208)

[Wolfgang Pieb via llvm-commits]

wolfy1961 wrote:

For some reason this is causing the test compiler-rt/test/fuzzer/gc-sections.test to fail on a vanilla Ubuntu 22.04 x86_64 machine with an asan failure:
```
INFO: Seed: 3367176086
INFO: Loaded 1 modules   (1 inline 8-bit counters): 1 [0x5653fa023928, 0x5653fa023929),
INFO: Loaded 1 PC tables (1 PCs): 1 [0x5653fa023930,0x5653fa023940),
INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 4096 bytes
INFO: A corpus is not provided, starting from an empty corpus
=================================================================
==1817959==ERROR: AddressSanitizer: alloc-dealloc-mismatch (malloc vs operator delete) on 0x516000000380
    #0 0x5653fa01b257  (/home/test/build/llvm/llvm-RelWithDebInfo/projects/compiler-rt/test/fuzzer/X86_64DefaultLinuxConfig/Output/gc-sections.test.tmp+0x1f1257)
    ...
    0x516000000380 is located 0 bytes inside of 513-byte region [0x516000000380,0x516000000581)
allocated by thread T0 here:
    #0 0x5653f9fdef1f  (/home/test/build/llvm/llvm-RelWithDebInfo/projects/compiler-rt/test/fuzzer/X86_64DefaultLinuxConfig/Output/gc-sections.test.tmp+0x1b4f1f)
    ...
```
Strangely, I don't see it reflected on any other buildbot anywhere, but some investigation shows the following:

The patch somehow seems to prevent asan instrumentation from intercepting operator new (allocating a string buffer in a fuzzer routine). Asan is only able to intercept the call to malloc(), and so it attributes it as being allocated by malloc. When the buffer is deallocated at the end of the routine, it is deallocated with operator delete, which asan treats as a mismatch of allocation types. 
When I generate the same executable with a compiler/linker built from the commit immediately preceding this one, asan does intercept operator new and the deallocation type matches the allocation type (i.e. from new).

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