* Re: [Keith Seitz] Re: [tools-team] Status 2008-09-01
@ 2009-09-23 14:08 Dragos Tatulea
2009-09-25 18:40 ` Tom Tromey
0 siblings, 1 reply; 7+ messages in thread
From: Dragos Tatulea @ 2009-09-23 14:08 UTC (permalink / raw)
To: keiths; +Cc: archer, jan.kratochvil, cmoller
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Keith Seitz] Re: [tools-team] Status 2008-09-01
2009-09-23 14:08 [Keith Seitz] Re: [tools-team] Status 2008-09-01 Dragos Tatulea
@ 2009-09-25 18:40 ` Tom Tromey
2009-09-25 19:39 ` Dragos Tatulea
0 siblings, 1 reply; 7+ messages in thread
From: Tom Tromey @ 2009-09-25 18:40 UTC (permalink / raw)
To: Dragos Tatulea; +Cc: keiths, archer, jan.kratochvil, cmoller
>>>>> "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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Keith Seitz] Re: [tools-team] Status 2008-09-01
2009-09-25 18:40 ` Tom Tromey
@ 2009-09-25 19:39 ` Dragos Tatulea
2009-09-25 20:45 ` Tom Tromey
0 siblings, 1 reply; 7+ messages in thread
From: Dragos Tatulea @ 2009-09-25 19:39 UTC (permalink / raw)
To: Tom Tromey; +Cc: keiths, archer, jan.kratochvil, cmoller
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Keith Seitz] Re: [tools-team] Status 2008-09-01
2009-09-25 19:39 ` Dragos Tatulea
@ 2009-09-25 20:45 ` Tom Tromey
2009-09-27 12:22 ` set print objct pros/cons [Re: [Keith Seitz] Re: [tools-team] Status 2008-09-01] Jan Kratochvil
0 siblings, 1 reply; 7+ messages in thread
From: Tom Tromey @ 2009-09-25 20:45 UTC (permalink / raw)
To: Dragos Tatulea; +Cc: keiths, archer, jan.kratochvil, cmoller
>>>>> "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
^ permalink raw reply [flat|nested] 7+ messages in thread
* set print objct pros/cons [Re: [Keith Seitz] Re: [tools-team] Status 2008-09-01]
2009-09-25 20:45 ` Tom Tromey
@ 2009-09-27 12:22 ` Jan Kratochvil
2009-09-27 17:14 ` Keith Seitz
0 siblings, 1 reply; 7+ messages in thread
From: Jan Kratochvil @ 2009-09-27 12:22 UTC (permalink / raw)
To: Tom Tromey; +Cc: Dragos Tatulea, keiths, archer, cmoller
[-- 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;
}
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: set print objct pros/cons [Re: [Keith Seitz] Re: [tools-team] Status 2008-09-01]
2009-09-27 12:22 ` set print objct pros/cons [Re: [Keith Seitz] Re: [tools-team] Status 2008-09-01] Jan Kratochvil
@ 2009-09-27 17:14 ` Keith Seitz
2009-09-27 18:26 ` Jan Kratochvil
0 siblings, 1 reply; 7+ messages in thread
From: Keith Seitz @ 2009-09-27 17:14 UTC (permalink / raw)
To: Jan Kratochvil; +Cc: archer
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: set print objct pros/cons [Re: [Keith Seitz] Re: [tools-team] Status 2008-09-01]
2009-09-27 17:14 ` Keith Seitz
@ 2009-09-27 18:26 ` Jan Kratochvil
0 siblings, 0 replies; 7+ messages in thread
From: Jan Kratochvil @ 2009-09-27 18:26 UTC (permalink / raw)
To: Keith Seitz; +Cc: archer
[-- 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;
}
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-09-27 18:26 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-09-23 14:08 [Keith Seitz] Re: [tools-team] Status 2008-09-01 Dragos Tatulea
2009-09-25 18:40 ` Tom Tromey
2009-09-25 19:39 ` Dragos Tatulea
2009-09-25 20:45 ` Tom Tromey
2009-09-27 12:22 ` set print objct pros/cons [Re: [Keith Seitz] Re: [tools-team] Status 2008-09-01] Jan Kratochvil
2009-09-27 17:14 ` Keith Seitz
2009-09-27 18:26 ` Jan Kratochvil
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).