This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gdb.c++ failures

>>>>> "Daniel" == Daniel Jacobowitz <> writes:

> On Thu, Jan 10, 2002 at 01:17:56PM +0000, Jason Merrill wrote:

>> classes.exp: dwarf2 doesn't provide mangled names for abstract
>> constructors, and there is a difference of opinion between the
>> demangler and c-typeprint.c as to whether the type should be written "A
>> const &" or "const A &".  The demangler always puts the cv-qualifier
>> after the type it affects, whereas gdb puts it in front whenever that
>> would have the correct meaning.  Either one could be changed to match
>> the other, or the testcase could be modified to accept either form.
>> Thoughts?

> The demangler should be left alone and the type printer updated, as far
> as I'm concerned - preferably to the GCC3 demangler style.

Works for me.

>> Also, gdb is including artificial arguments in the printed
>> representation of the constructors for vB-vD.  The dwarf2 output
>> indicates that they are artificial; gdb should not print them.  There
>> doesn't seem to be a simple way to handle this in the current gdb data
>> structures.

> What artificial arguments?  Or do you mean with GCC 2.95, where these
> tests are XFAILd because of this?

With dwarf2, the in-class abstract declaration of the constructor has
artificial parms for "in charge" and the VTT pointer.  The "in charge"
parameter is specialized away in both clones, and the VTT is is specialized
away in one of them, but both should be represented in the debug info,
ideally with DW_AT_const_value attributes where they have been specialized.

>> cplusfuncs.exp: cp-demangle bug.  The code to handle demangling
>> pointers-to-functions isn't complex enough.

> OK.  Would you mind marking the overly simplistic result as an XFAIL
> (or do you anticipate it being fixed soon?)

Will do.

>> method.exp: The 'print this' tests are failing because gdb is printing
>> the types as, say, (A * const), and the test just wants (A *).  The
>> former is correct, since 'this' is readonly.  Any objection to changing
>> the test (and others affected) to allow the const?

> The standard, or at least Stroustrop seems to disagree - this came up
> yesterday on gdb-patches.  He claims it should be A *, but not
> changeable.  I don't care.

Stroustrup is right; for whatever reason, the language specifies that
'this' is not an lvalue, so not only is it immutable, but you can't take
its address either.  I think it's more useful for the debugging information
to point at the hidden parameter used to pass the value of 'this' into the
function, for which A*const is a perfectly sensible type.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]