This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: What to do with info addr and location expressions
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Elena Zannoni <ezannoni at redhat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Fri, 18 Jul 2003 11:30:16 -0400
- Subject: Re: What to do with info addr and location expressions
- References: <16152.3014.959070.885970@localhost.redhat.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