Re: What to do with info addr and location expressions

[Daniel Jacobowitz <drow@mvista.com>]

On Fri, Jul 18, 2003 at 11:01:26AM -0400, Elena Zannoni wrote:
> 
> 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.

There are plenty of ways to fix it.  In general, we need a location
expression pretty-printer - this is quite complicated, so no one's done
it yet.  However, in specific, take a look at
locexpr_describe_location.  You could just add another case which
recognizes the form GCC emits for thread-local variables to fix the
regression.

Is that good enough?

> 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.

Yes, they're dead now.  Since the changes haven't caused any problems I
suppose they could be removed.  I was going to get is_thread_local when
I had finished with all the other users of decode_locdesc, but I
haven't had a chance to do that yet.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer