This is PR33173. More simple way to reproduce is below:
If we have tls.c file with line
__thread int a;
gcc -c tls.c -g
gives us R_X86_64_DTPOFF32 relocation in output:
Relocation section '.rela.debug_info' at offset 0x2e0 contains 6 entries: Offset Info Type Sym. Value Sym. Name + Addend 000000000006 00070000000a R_X86_64_32 0000000000000000 .debug_abbrev + 0 00000000000c 000a0000000a R_X86_64_32 0000000000000000 .debug_str + 26 000000000011 000a0000000a R_X86_64_32 0000000000000000 .debug_str + 54 000000000015 000a0000000a R_X86_64_32 0000000000000000 .debug_str + 0 000000000019 00090000000a R_X86_64_32 0000000000000000 .debug_line + 0 000000000028 000d00000015 R_X86_64_DTPOFF32 0000000000000000 a + 0
And run of llvm-dwarfdump tls.o would report "error: failed to compute relocation: R_X86_64_DTPOFF32"
error then, because such a relocation is not supported atm.
R_X86_64_DTPOFF32 calculates negative offset in the TLS block. Problem that size of TLS segment is not known
here. The same applies for PR33173 where we use RelocVisitor as part of DWARFContextInMemory for building .gdb_index.
TLS relocations pointing to .debug_info seems useless for index building purposes and we do not care about final value too.
So far it seems reasonable to have some value by default for TLS size, like 0 in this patch and some API that can be used in theory
if somebody needs to evaluate those TLS relocations.
That is what this patch do.