What to do with info addr and location expressions

What to do with info addr and location expressions

[Elena Zannoni]

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.


For the particular case at hand one could "cheat" and do like it was
done before, where, upon reading the value from the top of the stack
(which for the DW_GNU_push_tls_address case is the offset), such value
would be saved in the SYMBOL_VALUE field. If it was there, info
address would be able to access it. The offset is not changing over
time.

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.


elena

Re: What to do with info addr and location expressions

[Daniel Jacobowitz]

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

Re: What to do with info addr and location expressions

[Andrew Cagney]

[added binutils: gdb needs a way of printing out dwarf2 location 
expressions]

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

Why not share the readelf code?  Print both the actual expression and 
(for simple cases) an english translation.

Andrew

Re: What to do with info addr and location expressions

[Nick Clifton]

Hi Guys

> [added binutils: gdb needs a way of printing out dwarf2 location
> expressions]
>
> Why not share the readelf code?  Print both the actual expression and
> (for simple cases) an English translation.

readelf was not written with the intention of being used as a
library.  That does not mean however that the expression printing code
could not be moved into a separate file and then compiled in to both
gdb and readelf.

One thing though - readelf does not, and should not, used the bfd
library.  One of its main goals is to provide an alternative to bfd
for parsing and displaying ELF files, so that it can act as a
sanity/bug check.

Cheers
        Nick
        

Re: What to do with info addr and location expressions

[Jim Blandy]

Nick Clifton <nickc@redhat.com> writes:

> Hi Guys
> 
> > [added binutils: gdb needs a way of printing out dwarf2 location
> > expressions]
> >
> > Why not share the readelf code?  Print both the actual expression and
> > (for simple cases) an English translation.
> 
> readelf was not written with the intention of being used as a
> library.  That does not mean however that the expression printing code
> could not be moved into a separate file and then compiled in to both
> gdb and readelf.
> 
> One thing though - readelf does not, and should not, used the bfd
> library.  One of its main goals is to provide an alternative to bfd
> for parsing and displaying ELF files, so that it can act as a
> sanity/bug check.

The natural home for such code would be a libdwarf, but we don't have
that yet.  In the the mean time, could the code live in libiberty,
like the demangler?

Re: What to do with info addr and location expressions

[Andrew Cagney]

> 
> The natural home for such code would be a libdwarf, but we don't have
> that yet.  In the the mean time, could the code live in libiberty,
> like the demangler?

Please, no, not libiberty.

Andrew

Re: What to do with info addr and location expressions

[Nick Clifton]

Hi Jim,

>> One thing though - readelf does not, and should not, used the bfd
>> library.  One of its main goals is to provide an alternative to bfd
>> for parsing and displaying ELF files, so that it can act as a
>> sanity/bug check.
>
> The natural home for such code would be a libdwarf, but we don't have
> that yet.  In the the mean time, could the code live in libiberty,
> like the demangler?

I do not think that this is really suitable for libiberty.

The simplest method would be to break the code out into a separate
file that lives in the binutils/ directory and which could then be
compiled into either readelf or gdb.

Cheers
        Nick
        

Re: What to do with info addr and location expressions

[Daniel Berlin]

On Mon, 21 Jul 2003, Nick Clifton wrote:

> Hi Jim,
>
> >> One thing though - readelf does not, and should not, used the bfd
> >> library.  One of its main goals is to provide an alternative to bfd
> >> for parsing and displaying ELF files, so that it can act as a
> >> sanity/bug check.
> >
> > The natural home for such code would be a libdwarf, but we don't have
> > that yet.  In the the mean time, could the code live in libiberty,
> > like the demangler?
>
> I do not think that this is really suitable for libiberty.
>
> The simplest method would be to break the code out into a separate
> file that lives in the binutils/ directory and which could then be
> compiled into either readelf or gdb.

I'll go one better (or worse).

Since we don't know the binutils directory will be around when you
compiel gdb, why not make the functions (which are really trivial, and
just large switch statements) static inline, and put them in a
file somewhere in include/, a directory shared by all?


> > Cheers
>         Nick
>
>
>

Re: What to do with info addr and location expressions

[Doug Evans]

Daniel Berlin writes:
 > > The simplest method would be to break the code out into a separate
 > > file that lives in the binutils/ directory and which could then be
 > > compiled into either readelf or gdb.
 > 
 > I'll go one better (or worse).
 > 
 > Since we don't know the binutils directory will be around when you
 > compiel gdb, why not make the functions (which are really trivial, and
 > just large switch statements) static inline, and put them in a
 > file somewhere in include/, a directory shared by all?

[pedantic: inline conditional on gcc of course]

I'd rather not have gdb ship with ./binutils.

Why not create a new TLD named elf or dwarf or some such and include it
in binutils and gdb distributions.

I don't have an opinion on whether one would care whether this particular
directory has multiple libraries (libelf, libdwarf).
If one finds that unpalatable, call it dwarf and begin a libdwarf now
(or whatever).  It needed be all-singing/all-dancing in its first cut.

Re: What to do with info addr and location expressions

[Andrew Cagney]

> Hi Jim,
> 
> 
>>> One thing though - readelf does not, and should not, used the bfd
>>> library.  One of its main goals is to provide an alternative to bfd
>>> for parsing and displaying ELF files, so that it can act as a
>>> sanity/bug check.
> 
>>
>> The natural home for such code would be a libdwarf, but we don't have
>> that yet.  In the the mean time, could the code live in libiberty,
>> like the demangler?
> 
> 
> I do not think that this is really suitable for libiberty.
> 
> The simplest method would be to break the code out into a separate
> file that lives in the binutils/ directory and which could then be
> compiled into either readelf or gdb.

That would mean bundling the binutils directory in with GDB.  Hmm ...

Andrew

Re: What to do with info addr and location expressions

[DJ Delorie]

> That would mean bundling the binutils directory in with GDB.  Hmm ...

bfd/ perhaps?

Re: What to do with info addr and location expressions

[Nick Clifton]

Hi Guys,

> > Andrew wrote:
> > That would mean bundling the binutils directory in with GDB.  Hmm ...

> DJ replied:
> bfd/ perhaps?

Except that that then ruins the plan that readelf should be buildable
without libbfd.a.

> Doug wrote:
>
> I'd rather not have gdb ship with ./binutils.

OK.
 
> Why not create a new TLD named elf or dwarf or some such and include
> it in binutils and gdb distributions.
> 
> I don't have an opinion on whether one would care whether this particular
> directory has multiple libraries (libelf, libdwarf).
> If one finds that unpalatable, call it dwarf and begin a libdwarf now
> (or whatever).  It needed be all-singing/all-dancing in its first cut.

I would be open to this idea.

Cheers
        Nick
        

Re: What to do with info addr and location expressions

[DJ Delorie]

> > DJ replied:
> > bfd/ perhaps?
> 
> Except that that then ruins the plan that readelf should be buildable
> without libbfd.a.

Don't build it with libbfd.  Just keep it in the same directory.
There's no rule that says we can only have one library per directory.

Re: What to do with info addr and location expressions

[Nick Clifton]

Hi DJ,

>> > DJ replied:
>> > bfd/ perhaps?
>> 
>> Except that that then ruins the plan that readelf should be buildable
>> without libbfd.a.
>
> Don't build it with libbfd.  Just keep it in the same directory.
> There's no rule that says we can only have one library per directory.

Doh!  Yes, I should have realised that.

But that does mean that GDB would need the bfd/ sources, not just an
installed libbfd.a.  Is this OK with the GDB guys ?  If so, then I
have no objections.

Cheers
        Nick
        

Re: What to do with info addr and location expressions

[Daniel Jacobowitz]

On Tue, Jul 22, 2003 at 04:30:23PM +0100, Nick Clifton wrote:
> Hi DJ,
> 
> >> > DJ replied:
> >> > bfd/ perhaps?
> >> 
> >> Except that that then ruins the plan that readelf should be buildable
> >> without libbfd.a.
> >
> > Don't build it with libbfd.  Just keep it in the same directory.
> > There's no rule that says we can only have one library per directory.
> 
> Doh!  Yes, I should have realised that.
> 
> But that does mean that GDB would need the bfd/ sources, not just an
> installed libbfd.a.  Is this OK with the GDB guys ?  If so, then I
> have no objections.

GDB's already dependent on libbfd - and will probably stay that way.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: What to do with info addr and location expressions

[Elena Zannoni]

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

Re: What to do with info addr and location expressions

[Daniel Jacobowitz]

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