[PATCH] D82899: [ELF] Resolve R_DTPREL in .debug_* referencing discarded symbols to -1

[Fangrui Song via Phabricator via llvm-commits]

MaskRay added a comment.

In D82899#2124984 <https://reviews.llvm.org/D82899#2124984>, @jhenderson wrote:

> In D82899#2124699 <https://reviews.llvm.org/D82899#2124699>, @jhenderson wrote:
>
> > Sorry, I don't follow why we can't just use this approach for all relocations referencing dead allocatable code/data? We should probably only get certain relocations, or b) not fixing up things when a new relocation gets introduced in the future.
>


If we want to support R_X86_64_32, we'll need to truncate UINT64_MAX, i.e. we'll need some code somewhere. I'd rather do it with existing `type == target->symbolicRel`.

> but I could see us either a) easily missing another relevant one

No, there is not a need for another R_ABS relocation. For new relocation types, we should evaluate them, rather than being loose and using -1 for every new relocation type.

> To add to this, reading up on the TLS documentation, at least for X86_64, it is possible to sometimes use R_X86_64_32 instead of R_X86_64_DTPOFF32, although I don't know if that situation would ever occur in debug data.

R_X86_64_{32,64} referencing a STT_TLS is incorrect.

- R_X86_64_64: load_base + st_value + r_addend
- R_X86_64_DTPOFFSET{32,64}: st_value + r_addend - DTP_OFFSET

DTP_OFFSET is musl term. glibc calls it TLS_DTV_OFFSET. On x86-64, DTP_OFFSET is 0 so mixing is correct if

source: http://git.musl-libc.org/cgit/musl/tree/ldso/dynlink.c#n454 I am confident with the code as I've reported a musl issue in this area and fixed a few TLS bugs in LLD.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82899/new/

https://reviews.llvm.org/D82899