Re: [Keith Seitz] Re: [tools-team] Status 2008-09-01

Re: [Keith Seitz] Re: [tools-team] Status 2008-09-01

[Dragos Tatulea]

Hi Keith,

> That is, I think "set print object on" ought to affect the type of the
> resulting history variable -- but not the type of any intermediate
> values in an expression.
>
> Jan> One should change this (+some other related options in
> Jan> `user_print_options') and in some way fix the testsuite regressions
> Jan> afterwards by one of:
>
> I agree, we should change this default.

I changed objectprint to on by default on Jan's suggestion, but this breaks some
other cases like this one (from ptr-typedef test)

struct foo {
  int x;
};

typedef struct foo *foz;

int
main (void)
{
  foz_ptr = NULL;
}

gdb> p foz_ptr
$1 = (struct foo *) 0x0
instead of
(foz*)

So the change isn't acceptable.

Back to the previous case: Jan suggested printing an error/warning for the user
saying that the ptr has a different type (and maybe printing the type). What do
you think?

Thanks,
Dragos

Re: [Keith Seitz] Re: [tools-team] Status 2008-09-01

[Tom Tromey]

>>>>> "Dragos" == Dragos Tatulea <dragos.tatulea@gmail.com> writes:

Dragos> I changed objectprint to on by default on Jan's suggestion, but
Dragos> this breaks some other cases like this one (from ptr-typedef
Dragos> test)

Dragos> gdb> p foz_ptr
Dragos> $1 = (struct foo *) 0x0
Dragos> instead of
Dragos> (foz*)

This seems like a generic bug, though.  So, it could be fixed either
separately or at the same time the default is flipped.

Dragos> Back to the previous case: Jan suggested printing an
Dragos> error/warning for the user saying that the ptr has a different
Dragos> type (and maybe printing the type). What do you think?

I think it depends on how often the warning would trigger, and where it
would be printed (e.g., would it show up mid-struct?).

Tom

Re: [Keith Seitz] Re: [tools-team] Status 2008-09-01

[Dragos Tatulea]

Hi,

> Dragos> I changed objectprint to on by default on Jan's suggestion, but
> Dragos> this breaks some other cases like this one (from ptr-typedef
> Dragos> test)
>
> Dragos> gdb> p foz_ptr
> Dragos> $1 = (struct foo *) 0x0
> Dragos> instead of
> Dragos> (foz*)
>
> This seems like a generic bug, though.  So, it could be fixed either
> separately or at the same time the default is flipped.
>
Why is this a bug? Isn't objectprint supposed to follow up to the original/true
type?

> Dragos> Back to the previous case: Jan suggested printing an
> Dragos> error/warning for the user saying that the ptr has a different
> Dragos> type (and maybe printing the type). What do you think?
>
> I think it depends on how often the warning would trigger, and where it
> would be printed (e.g., would it show up mid-struct?).
>
Maybe it's not such a good idea to show up in mid struct. Maybe display the
usual output and then print warnings on following lines. Dunno' if it's actually
possible (noob alert!).

-- Dragos

Re: [Keith Seitz] Re: [tools-team] Status 2008-09-01

[Tom Tromey]

>>>>> "Dragos" == Dragos Tatulea <dragos.tatulea@gmail.com> writes:

Tom> This seems like a generic bug, though.  So, it could be fixed either
Tom> separately or at the same time the default is flipped.

Dragos> Why is this a bug? Isn't objectprint supposed to follow up to
Dragos> the original/true type?

I see what you mean.

But, it seems like it would be a little more user-friendly to print the
original type name if we examine the runtime type and find that it is
identical to the declared type (after typdef stripping).

Dragos> Maybe it's not such a good idea to show up in mid struct. Maybe
Dragos> display the usual output and then print warnings on following
Dragos> lines. Dunno' if it's actually possible (noob alert!).

Probably not easily, but I'm sure it could be managed.
But, when printing a long structure this is likely to be more confusing.

Tom

set print objct pros/cons [Re: [Keith Seitz] Re: [tools-team] Status 2008-09-01]

[Jan Kratochvil]

[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]

Hi,

just found out `set print object on' is not such a clear win:

(gdb) b 27
Breakpoint 1 at 0x40069b: file cxxinherit.C, line 27.
(gdb) r
Starting program: /home/jkratoch/t/cxxinherit 
derived::m
base::m
Breakpoint 1, main () at cxxinherit.C:27
27	  return 0;
(gdb) show print object 
Printing of object's derived type based on vtable info is off.
(gdb) p derivedp->m
$1 = {void (Derived *)} 0x4006c4 <Derived::m()>
(gdb) p basep->m
$2 = {void (Base *)} 0x4006a2 <Base::m()>
(gdb) call derivedp->m ()
derived::m
(gdb) call basep->m ()
base::m
(gdb) set print object on
(gdb) p derivedp->m
$3 = {void (Derived *)} 0x4006c4 <Derived::m()>
(gdb) p basep->m
$4 = {void (Derived *)} 0x4006c4 <Derived::m()>
(gdb) call derivedp->m ()
derived::m
(gdb) call basep->m ()
base::m


(1) Last "call basep->m ()" should have printed "derived::m"
    because "p basep->m" prints "Derived::m()", shouldn't it?

(2) A lookup can succeed in both "off" and "on" cases with different results.

One should fix (1) as it looks just as a bug to me.

Afterwards for (2) maybe any C++ print should be evaluated both ways and if
the resulting `struct value' differs it should print both values with a warning?

("any C++ print" could be optimized somehow, not the point here.)


Thanks,
Jan

[-- Attachment #2: cxxinherit.C --]
[-- Type: text/plain, Size: 396 bytes --]

#include <stdio.h>

class Base
  {
  public:
    void m () { puts ("base::m"); }
    virtual void stub () {}
  };

class Derived : public Base
  {
  public:
    virtual void m () { puts ("derived::m"); }
    virtual void stub () {}
  };

int
main ()
{
  Derived derived_local;
  Derived *derivedp = &derived_local;
  Base *basep = &derived_local;

  derivedp->m ();
  basep->m ();

  return 0;
}

Re: set print objct pros/cons [Re: [Keith Seitz] Re: [tools-team] Status 2008-09-01]

[Keith Seitz]

On 09/27/2009 05:21 AM, Jan Kratochvil wrote:
>
> (1) Last "call basep->m ()" should have printed "derived::m"
>      because "p basep->m" prints "Derived::m()", shouldn't it?
>

basep->m will always print "base::m" -- your test case did not declare 
Base::m virtual. Or is that just an omission in the file you attached?

> (2) A lookup can succeed in both "off" and "on" cases with different results.

Indeed. I believe gdb should stick to the language rules, "print object" 
or not. We need to break the unwritten gdb development rule that 
everything must have a freakin' switch in the debugger. It's 
unscalable/unmanageable/user-unfriendly. IMO, "object print" should not 
even exist at all.

Keith

Re: set print objct pros/cons [Re: [Keith Seitz] Re: [tools-team] Status 2008-09-01]

[Jan Kratochvil]

[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]

On Sun, 27 Sep 2009 19:14:22 +0200, Keith Seitz wrote:
> On 09/27/2009 05:21 AM, Jan Kratochvil wrote:
> >
> >(1) Last "call basep->m ()" should have printed "derived::m"
> >     because "p basep->m" prints "Derived::m()", shouldn't it?
> >
> 
> basep->m will always print "base::m" -- your test case did not
> declare Base::m virtual. Or is that just an omission in the file you
> attached?

It was intentional that way (unaware how common it is in C++ to override
non-virtual method name by a virtual one, though).

I think the following two commands should deal with the same pointer, whithout
even talking about which pointer ("Derived::m" or "Base::m") it should be:

It does not work now - with the previous testcase cxxinherit.C:
	(gdb) set print object on
	(gdb) p basep->m
	$4 = {void (Derived *)} 0x4006c4 <Derived::m()>
	(gdb) call basep->m ()
	base::m


> IMO, "object print" should not even exist at all.

Currently the "off" mode does not work right for the virtual/virtual case:

With the new attached testcase cxxinherit2.C:
	Starting program: /home/jkratoch/t/cxxinherit2 
	derived::m
	derived::m
	Breakpoint 1, main () at cxxinherit2.C:27
	27	  return 0;
	(gdb) show print object 
	Printing of object's derived type based on vtable info is off.
	(gdb) call basep->m ()
	derived::m
	(gdb) p basep->m
	$1 = {void (Base *)} 0x4006a6 <Base::m()>
	(gdb) 


Regards,
Jan

[-- Attachment #2: cxxinherit2.C --]
[-- Type: text/plain, Size: 404 bytes --]

#include <stdio.h>

class Base
  {
  public:
    virtual void m () { puts ("base::m"); }
    virtual void stub () {}
  };

class Derived : public Base
  {
  public:
    virtual void m () { puts ("derived::m"); }
    virtual void stub () {}
  };

int
main ()
{
  Derived derived_local;
  Derived *derivedp = &derived_local;
  Base *basep = &derived_local;

  derivedp->m ();
  basep->m ();

  return 0;
}