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