Re: What to do with info addr and location expressions

[Daniel Jacobowitz <drow at mvista dot com>]

On Fri, Jul 18, 2003 at 12:08:44PM -0400, Elena Zannoni wrote:
> 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'.

Ah, but I don't agree in general.  Here's an example.  Suppose you have
a variable whose location includes DW_OP_deref - GCC does generate
this.  If you just work out the location and say "this variable is
currently at 0x08001200", then you're not giving the whole story.  It's
actually "this variable's address is in memory at *$eax - currently
0x08001200".

[What should "print &x" say in that case?  No idea.]

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

Thank you!

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer