What to do with info addr and location expressions

[Elena Zannoni <ezannoni@redhat.com>]

I was looking at the tls tests, and was trying to understand why
Michael was seeing failures and I wasn't. I discovered that I was
testing the old RH gdb version which was based on a snapshot taken
befor the dwarf2loc* and dwarf2expr* files where introduced.

Turns out that we lost a whole lot of information in the 'info address'
command.

Before the change:

(gdb) info address a_thread_local
Symbol "a_thread_local" is a thread-local variable at offset 0 in the thread-local storage for `/usr/src/redhat/BUILD/gdb+dejagnu-20021129-build/gdb/testsuite/gdb.threads/tls'.
(gdb) info address another_thread_local
Symbol "another_thread_local" is a thread-local variable at offset 4 in the thread-local storage for `/usr/src/redhat/BUILD/gdb+dejagnu-20021129-build/gdb/testsuite/gdb.threads/tls'.



after the change:


(gdb) info address a_thread_local
Symbol "a_thread_local" is a variable with complex or multiple locations (DWARF2).
(gdb) info address another_thread_local
Symbol "another_thread_local" is a variable with complex or multiple locations (DWARF2).


Seems to me like a regression because we have lost some information. 


Is there any way to fix this? I.e. is there any way to recalculate the
values as part of info address? Could info address call
locexpr_read_variable or a variant of it? I always found info address
quite useful.


For the particular case at hand one could "cheat" and do like it was
done before, where, upon reading the value from the top of the stack
(which for the DW_GNU_push_tls_address case is the offset), such value
would be saved in the SYMBOL_VALUE field. If it was there, info
address would be able to access it. The offset is not changing over
time.

BTW, when this changes were checked in, a few things used by TLS
weren't cleaned up properly, like the global is_thread_local and the
enum value LOC_THREAD_LOCAL_STATIC, with the cases in printcmd.c and
findvar.c.


elena