Re: [patch/testsuite/c++] test script for PR c++/186

[mec.gnu@mindspring.com (Michael Elizabeth Chastain)]

Hi David,
> I wouldn't necessarily call this incorrect/wrong, but it is somewhat
> unfortunate.  I confess, though, that the correct fix isn't at all
> obvious to me, given that normally the dynamic type is more useful
> than the static type.  Should GDB try to somehow take the supremum of
> the static type and the dynamic type?  (And what if there is no
> supremum?)  Should GDB try to remember when the user explicitly casts?
> (If so, exactly how do we want to remember that?)  Should there be an
> option to turn of RTTI usage?  (But users won't know about that.)

Well, gdb does have "set print object", which defaults to "off".

There are really two points here.  One is that gdb has to decide
which type to print.  There is the static type of the expression,
and the dynamic type in memory, and the value of "set print object"
to consider.

But beyond that level, gdb is printing bogus values.  Specifically: I've
got these two classes, "A" and "B".  "B" is derived from "A".  I've got
an object that used to be a "B", but thanks to B::~B, the dynamic type
is actually "A" by now.  When I say "print *pb", gdb prints values for
the fields of B.  But it prints bogus data, and it prints *different*
bogus data on successive calls.  It's not like gdb is choosing an
infelicitous type and forcing the target memory into that type, it's like 
gdb is dereferencing wild pointers internally.

I suspect that gdb is using the static type to decide "let's print the B
type", but is using the dynamic type to find things, without any error
checking.  Something like:

  for (i = 0; i < static_type->nfields; i++)
    {
      ... dynamic_type->fields[i] ...
    }

The dynamic type is a parent of the static type (thanks to the
destructor) so it has fewer fields.

> Maybe the best thing to do would be as follows, if A is the dynamic
> type and B is the static type, then we check to make sure that A is
> more specialized than B.

Hmmm, that would be one way of fixing the problem, I think.  Code like
the above actually works if you can assert that dynamic_type is derived
from static_type.

But I would rather that gdb have a more clear notion of which type
information it is using -- pick one type and then stick with it.
It's just asking for trouble if there is code like the above.

Michael C