Re: What to do with info addr and location expressions

[Elena Zannoni <ezannoni@redhat.com>]

Daniel Jacobowitz writes:
 > 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.

Yes, I have looked at the function. I can see a ways to hack around
the problem, but I don't see a clear proper fix that doesn't require
some extensive work. Info addr was giving you a lot of info. :-( It's
not just a pretty printer that is needed here.  You need to compute
the values, and print the address. Kind of like the 'whatis' command
does wrt to 'print'.

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

Yes, obviously they were dead as soon as the changes were
committed. That's why I was puzzled to see that they were still there,
totally dead code, w/o any comments.

I'll clean that up.

elena


 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer