Simplify decode_locdesc
authorTom Tromey <tom@tromey.com>
Fri, 7 Apr 2023 21:31:43 +0000 (15:31 -0600)
committerTom Tromey <tom@tromey.com>
Fri, 5 May 2023 15:01:36 +0000 (09:01 -0600)
commit233239384c7a050dd590971d75233c49b12f8d85
treef0b711716287a0b74e37a506051eea59da17846e
parent02601231fdd91a7bd4837ce202906ea2ce661489
Simplify decode_locdesc

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.
gdb/dwarf2/read.c