forked from Imagelibrary/binutils-gdb
233239384c
While looking into another bug, I noticed that the DWARF cooked
indexer picks up an address for this symbol:
<1><82>: Abbrev Number: 2 (DW_TAG_variable)
<83> DW_AT_specification: <0x9f>
<87> DW_AT_location : 10 byte block: e 0 0 0 0 0 0 0 0 e0 (DW_OP_const8u: 0 0; DW_OP_GNU_push_tls_address or DW_OP_HP_unknown)
<92> DW_AT_linkage_name: (indirect string, offset: 0x156): _ZN9container8tlsvar_0E
This happens because decode_locdesc allows the use of
DW_OP_GNU_push_tls_address.
This didn't make sense to me. I looked into it a bit more, and I
think decode_locdesc is used in three ways:
1. Find a constant address of a symbol that happens to be encoded as a
location expression.
2. Find the offset of a function in a virtual table. (This one should
probably be replaced by code to just evaluate the expression in
gnu-v3-abi.c -- but there's no point yet because no compiler
actually seems to emit correct DWARF here, see the bug linked in
the patch.)
3. Find the offset of a field, if the offset is a constant.
None of these require TLS.
This patch simplifies decode_locdesc by removing any opcodes that
don't fit into the above. It also changes the API a little, to make
it less difficult to use.
Regression tested on x86-64 Fedora 36.