Fangrui Song 8abf8d124a
[ELF] Don't resolve relocations referencing SHN_ABS to tombstone in non-SHF_ALLOC sections (#79238)
A SHN_ABS symbol has never been considered for
InputSection::relocateNonAlloc.
Before #74686, the code did made it work in the absence of `-z
dead-reloc-in-nonalloc=`.
There is now a report about such SHN_ABS uses

(https://github.com/llvm/llvm-project/pull/74686#issuecomment-1904101711)
and I think it makes sense for non-SHF_ALLOC to support SHN_ABS, like
SHF_ALLOC sections do.

```
// clang -g
__attribute__((weak)) int symbol;
int *foo() { return &symbol; }

0x00000023:   DW_TAG_variable [2]   (0x0000000c)
                ...
                DW_AT_location [DW_FORM_exprloc]        (DW_OP_addrx 0x0)

```

.debug_addr references `symbol`, which can be redefined by a symbol
assignment or --defsym to become a SHN_ABS symbol.

The problem is that `!sym.getOutputSection()` cannot discern SHN_ABS
from a symbol whose section has been discarded. Since commit
1981b1b6b92f7579a30c9ed32dbdf3bc749c1b40, a symbol relative to a
discarded section is changed to `Undefined`, so the `SHN_ABS` check
become trivial.

We currently apply tombstone for a relocation referencing
`SharedSymbol`. This patch does not change the behavior.
2024-01-24 08:53:36 -08:00
..
2024-01-23 12:52:36 -08:00
2021-02-08 08:55:29 -08:00
2023-05-02 09:34:48 +08:00
2023-08-21 09:11:51 -07:00
2024-01-22 09:09:46 -08:00
2020-03-27 11:56:02 -07:00
2022-08-15 18:49:02 -04:00
2021-01-22 19:07:02 -08:00
2021-10-04 11:10:10 +01:00
2021-10-04 11:10:10 +01:00
2021-10-04 11:10:10 +01:00
2021-10-04 11:10:10 +01:00
2020-08-07 22:08:44 -07:00
2023-07-18 17:57:31 -07:00
2022-08-02 09:52:31 -04:00
2020-06-01 10:19:41 -07:00
2023-07-25 17:06:07 +08:00
2023-07-25 17:06:07 +08:00
2022-01-15 22:33:51 -08:00
2022-01-15 22:33:51 -08:00
2022-10-24 10:54:09 -07:00
2022-01-29 14:45:58 -08:00
2023-07-18 17:57:31 -07:00
2022-09-20 17:12:44 -07:00
2022-10-24 10:54:09 -07:00
2021-10-31 12:10:43 -07:00