Re: [rfc] Decode "is a variable with complex or multiple locations" (PR 8399)

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> (b) It prints it in a human readable format so more complex
Jan> expressions are still not decoded.
Jan>     GDB should probably reuse
Jan>     binutils/dwarf.c:decode_location_expression().
Jan> (b1) http://sources.redhat.com/ml/gdb/2003-07/msg00242.html
Jan> discussion had no conclusion where the code should be placed
Jan> (probably bfd/file-no-in-libbfd.a).

Ask on the binutils list.  I'm sure we can arrive at a place to store
it.  We can always make a new library in bfd/, or anywhere.

Jan> (c) "a variable in register rsi" vs. "DW_OP_reg4":

Jan> (c1) Extending the readelf<->gdb shared code to print register
Jan> names (4->rsi) may not be acceptable for arch-independent readelf.

We can add a callback that GDB would use to supply the register name.

Jan> (c2) "in register SOMENAME" is more user friendly than "DW_OP_reg42".
Jan>      But too complex expression cannot be printed in a user friendly way.

I think it is fine to show it in "assembly-like" form using the DW_OP
names, because it is better to expose things for users who do understand
them than to hide them from users who don't.  If we get too many
complaints, we can add an option.q

Jan> (c3) Is it OK to break backward compatibility by printing
Jan> "DW_OP_reg*" (either numerically or with register-names)?

IMO, yes.

Tom