print/x on references

print/x on references

[Paul Hilfinger]

Currently, there is a slight discrepancy in the behavior of formatted print
commands.  Stop the program below in f.  At that point, we see the
following behavior:

    (gdb) p x
    $4 = (Glorp &) @0x8049850: {x = 1, y = 2}
    (gdb) p/x x
    $5 = 0x8049850

Is there any particular reason these two cases shouldn't have the same
behavior?  It seems that printcmd.c:print_formatted is conflating the
cases of C++ pointers and C++ references, and I don't see the justification
for doing so.  True, it's easy enough to kludge around:

    (gdb) p/x *&x

But it is slightly annoying to have to do this.  Admittedly, I'm speaking
more from the Ada camp, where the equivalent kludge is more verbose (and
from the user's point of view, less motivated).

Still, would anyone object if this behavior were to change?

P. Hilfinger

------------------------------------------------------------


#include <iostream>

using namespace std;

struct Glorp {
  int x, y;
};

Glorp z = { 1, 2 };

void f (Glorp& x) {
  cout << x.x << ", " << x.y << endl;
}

main () {
  f(z);
}

Re: print/x on references

[Daniel Jacobowitz]

On Thu, Oct 18, 2007 at 05:37:36AM -0400, Paul Hilfinger wrote:
> 
> Currently, there is a slight discrepancy in the behavior of formatted print
> commands.  Stop the program below in f.  At that point, we see the
> following behavior:
> 
>     (gdb) p x
>     $4 = (Glorp &) @0x8049850: {x = 1, y = 2}
>     (gdb) p/x x
>     $5 = 0x8049850
> 
> Is there any particular reason these two cases shouldn't have the same
> behavior?  It seems that printcmd.c:print_formatted is conflating the
> cases of C++ pointers and C++ references, and I don't see the justification
> for doing so.

Well, what's the right behavior?  I'm not thrilled with the current
behavior either, but I don't want to make it too hard to get at the
reference's "value" i.e. pointer.  In C++ you never (are supposed to)
need that, but while debugging is in my opinion a different story.

-- 
Daniel Jacobowitz
CodeSourcery

Re: print/x on references

[Douglas Evans]

On 10/18/07, Daniel Jacobowitz <drow@false.org> wrote:
> On Thu, Oct 18, 2007 at 05:37:36AM -0400, Paul Hilfinger wrote:
> >
> > Currently, there is a slight discrepancy in the behavior of formatted print
> > commands.  Stop the program below in f.  At that point, we see the
> > following behavior:
> >
> >     (gdb) p x
> >     $4 = (Glorp &) @0x8049850: {x = 1, y = 2}
> >     (gdb) p/x x
> >     $5 = 0x8049850
> >
> > Is there any particular reason these two cases shouldn't have the same
> > behavior?  It seems that printcmd.c:print_formatted is conflating the
> > cases of C++ pointers and C++ references, and I don't see the justification
> > for doing so.
>
> Well, what's the right behavior?  I'm not thrilled with the current
> behavior either, but I don't want to make it too hard to get at the
> reference's "value" i.e. pointer.  In C++ you never (are supposed to)
> need that, but while debugging is in my opinion a different story.

(gdb) p/x x -> prints same as $4 but in hex
(gdb) p &x -> prints pointer (e.g. "$5 = (Glorp *) 0x8049850")

$0.02

Re: print/x on references

[Daniel Jacobowitz]

On Thu, Oct 18, 2007 at 09:04:48AM -0700, Douglas Evans wrote:
> (gdb) p/x x -> prints same as $4 but in hex
> (gdb) p &x -> prints pointer (e.g. "$5 = (Glorp *) 0x8049850")
> 
> $0.02

And then there's no way to find the address of the reference?

-- 
Daniel Jacobowitz
CodeSourcery

Re: print/x on references

[Douglas Evans]

On 10/18/07, Daniel Jacobowitz <drow@false.org> wrote:
> On Thu, Oct 18, 2007 at 09:04:48AM -0700, Douglas Evans wrote:
> > (gdb) p/x x -> prints same as $4 but in hex
> > (gdb) p &x -> prints pointer (e.g. "$5 = (Glorp *) 0x8049850")
> >
> > $0.02
>
> And then there's no way to find the address of the reference?

To find the address of the pointer to the object I was thinking "p
&(&x)".  It works, at least in the simple example I used to experiment
with.

Am I misunderstanding your point?  [quite likely - apologies]

Re: print/x on references

[Douglas Evans]

On 10/18/07, Douglas Evans <dje@google.com> wrote:
> To find the address of the pointer to the object I was thinking "p
> &(&x)".  It works, at least in the simple example I used to experiment
> with.
>
> Am I misunderstanding your point?  [quite likely - apologies]

Heh ... or used too simplistic an example.  Here it is fwiw.

class c
{
  int i;
};

void
foo (c& cref)
{
}

int
main ()
{
  c cobj;
  foo (cobj);
}

dje@ruffy:~/src$ gdb a.out
GNU gdb 6.7.50-20071017-cvs
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux"...
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) b foo
Breakpoint 1 at 0x8048357: file ref-printing.cc, line 9.
(gdb) r
Starting program: /home/dje/src/a.out

Breakpoint 1, foo (cref=@0xffffd864) at ref-printing.cc:9
9       }
(gdb) info frame
Stack level 0, frame at 0xffffd840:
 eip = 0x8048357 in foo(c&) (ref-printing.cc:9); saved eip 0x8048381
 called by frame at 0xffffd870
 source language c++.
 Arglist at 0xffffd838, args: cref=@0xffffd864
 Locals at 0xffffd838, Previous frame's sp is 0xffffd840
 Saved registers:
  ebp at 0xffffd838, eip at 0xffffd83c
(gdb) p cref
$1 = (c &) @0xffffd864: {i = 1334422496}
(gdb) p &cref
$2 = (c *) 0xffffd864
(gdb) p &(&cref)
$3 = (c **) 0xffffd840
(gdb) x/4x $ebp
0xffffd838:     0xffffd868      0x08048381      0xffffd864      0x416ed604
(gdb)

Re: print/x on references

[Daniel Jacobowitz]

On Thu, Oct 18, 2007 at 10:03:01AM -0700, Douglas Evans wrote:
> On 10/18/07, Daniel Jacobowitz <drow@false.org> wrote:
> > On Thu, Oct 18, 2007 at 09:04:48AM -0700, Douglas Evans wrote:
> > > (gdb) p/x x -> prints same as $4 but in hex
> > > (gdb) p &x -> prints pointer (e.g. "$5 = (Glorp *) 0x8049850")
> > >
> > > $0.02
> >
> > And then there's no way to find the address of the reference?
> 
> To find the address of the pointer to the object I was thinking "p
> &(&x)".  It works, at least in the simple example I used to experiment
> with.

That is such a horrible abuse of C++ that I didn't even think to try
it.  Egads.  Not quite sure how I feel about that!

-- 
Daniel Jacobowitz
CodeSourcery

Re: print/x on references

[Douglas Evans]

On 10/18/07, Daniel Jacobowitz <drow@false.org> wrote:
> On Thu, Oct 18, 2007 at 10:03:01AM -0700, Douglas Evans wrote:
> > To find the address of the pointer to the object I was thinking "p
> > &(&x)".  It works, at least in the simple example I used to experiment
> > with.
>
> That is such a horrible abuse of C++ that I didn't even think to try
> it.  Egads.  Not quite sure how I feel about that!

fwiw,
I think the expression evaluator should work as the language does (as
much as possible).  And once it does that then thought is given to
whatever extensions are needed to accomplish things not possible with
the language syntax.
e.g. "p cut-n-pasted-expression-from-source" should "just work" (to
some reasonable extent).

Given that, to me "p &cref" -> (c*) and not (c**) follows naturally
out of c++ syntax.  Whatever goop we want to add to get at the address
of the object containing the reference is separate.  "p &(&cref)" is
the first thing that came to mind and wonderfully it "just worked".
One may want a different (or additional) way to achieve this of
course, but it should not break "p &cref" -> (c*).

fwiw of course.

Re: print/x on references

[Paul Hilfinger]

 > > > To find the address of the pointer to the object I was thinking "p
 > > > &(&x)"...

 > > That is such a horrible abuse of C++ that I didn't even think to try
 > > it....
 > 
 > I think the expression evaluator should work as the language does (as
 > much as possible).  And once it does that then thought is given to
 > whatever extensions are needed to accomplish things not possible with
 > the language syntax.
 > e.g. "p cut-n-pasted-expression-from-source" should "just work" (to
 > some reasonable extent).

Or, to put it rhetorically, it is fitting that &(&x) (for x of type
Glorp&) is a horrible abuse of C++, since in C++ the type Glorp&* does
not exist!

PNH

Re: print/x on references

[Daniel Jacobowitz]

On Thu, Oct 18, 2007 at 10:45:14AM -0700, Douglas Evans wrote:
> fwiw,
> I think the expression evaluator should work as the language does (as
> much as possible).  And once it does that then thought is given to
> whatever extensions are needed to accomplish things not possible with
> the language syntax.
> e.g. "p cut-n-pasted-expression-from-source" should "just work" (to
> some reasonable extent).
> 
> Given that, to me "p &cref" -> (c*) and not (c**) follows naturally
> out of c++ syntax.  Whatever goop we want to add to get at the address
> of the object containing the reference is separate.  "p &(&cref)" is
> the first thing that came to mind and wonderfully it "just worked".
> One may want a different (or additional) way to achieve this of
> course, but it should not break "p &cref" -> (c*).

That is an excellent explanation.  You've convinced me.

Either of you want to write us some testcases for the testsuite?

-- 
Daniel Jacobowitz
CodeSourcery

Re: print/x on references

[Paul Hilfinger]

> Either of you want to write us some testcases for the testsuite?

Sure, and I can also submit a patch to current behavior (since I
opened this particular can).  Shall we test p/x &(&c) as well as p/x c
and p/x &c (and the analogous Ada cases, which are identical except
for syntax)?

PNH

Re: print/x on references

[Daniel Jacobowitz]

On Thu, Oct 18, 2007 at 12:30:21PM -0700, Paul Hilfinger wrote:
> 
> > Either of you want to write us some testcases for the testsuite?
> 
> Sure, and I can also submit a patch to current behavior (since I
> opened this particular can).  Shall we test p/x &(&c) as well as p/x c
> and p/x &c (and the analogous Ada cases, which are identical except
> for syntax)?

What the heck - let's test and document it.

-- 
Daniel Jacobowitz
CodeSourcery

Re: print/x on references

[Jim Blandy]

Daniel Jacobowitz <drow at false.org> writes:
> On Thu, Oct 18, 2007 at 10:45:14AM -0700, Douglas Evans wrote:
>> fwiw,
>> I think the expression evaluator should work as the language does (as
>> much as possible).  And once it does that then thought is given to
>> whatever extensions are needed to accomplish things not possible with
>> the language syntax.
>> e.g. "p cut-n-pasted-expression-from-source" should "just work" (to
>> some reasonable extent).
>> 
>> Given that, to me "p &cref" -> (c*) and not (c**) follows naturally
>> out of c++ syntax.  Whatever goop we want to add to get at the address
>> of the object containing the reference is separate.  "p &(&cref)" is
>> the first thing that came to mind and wonderfully it "just worked".
>> One may want a different (or additional) way to achieve this of
>> course, but it should not break "p &cref" -> (c*).
>
> That is an excellent explanation.  You've convinced me.

It turns out this is actually documented in the manual:

File: gdb.info,  Node: C Operators

...

`&'
     Address operator.  Defined on variables.  Same precedence as `++'.

     For debugging C++, GDB implements a use of `&' beyond what is
     allowed in the C++ language itself: you can use `&(&REF)' (or, if
     you prefer, simply `&&REF') to examine the address where a C++
     reference variable (declared with `&REF') is stored.

Re: print/x on references

[Daniel Jacobowitz]

On Fri, Oct 19, 2007 at 02:40:32PM -0700, Jim Blandy wrote:
>      For debugging C++, GDB implements a use of `&' beyond what is
>      allowed in the C++ language itself: you can use `&(&REF)' (or, if
>      you prefer, simply `&&REF') to examine the address where a C++
>      reference variable (declared with `&REF') is stored.

Good for us.  Shame on us for having no test cases for it!  I wonder
if &&REF really works.

-- 
Daniel Jacobowitz
CodeSourcery