[llvm] [dsymutil][DWARFLinker] Refactor handling mergeable libraries. (PR #80615)

[Alexey Lapshin via llvm-commits]

avl-llvm wrote:

> I don't think this new approach covers all cases. The initial implementation of llvm-dsymutil didn't care about relocations and would just go through the Dwarf and patch things that looked like they needed patching like the low_pc of functions. I discovered that these are however not the only places where relocations occur. Global variables have relocations too, and weirdly I've seen relocations in the middle of a complex Dwarf location expression. Falling back on actually relocation processing was the way we handled these cases.

My understanding is that this new patch does not broke this behavior. Let`s see how it work for global variables:

1. file foo.o has following definition for some global variable:
   
```
   DW_TAG_variable
     DW_AT_name var1
     DW_AT_location  "DW_OP_addr 0x1000"  <<< object file contains a relocation for DW_OP_addr value.

```     
2. when dsymutil links foo.o into foo.dylib it links relocation through the debug map. The foo.dylib
   will contain following:
   
```
   DW_TAG_variable
     DW_AT_name var1
     DW_AT_location  "DW_OP_addr 0x2000"  <<< dylib contains absolute linked value.

```
3. when dsymutil links another file referencing foo.dylib it reads absolute value 0x2000 and 
   links it through the new debug map. So the final file contains:

```
   DW_TAG_variable
     DW_AT_name var1
     DW_AT_location  "DW_OP_addr 0x3000"  <<< final file contains absolute relinked value.

```

Are there cases which would be handled incorrectly using this scheme?

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