Re: beta patch for PR 9065

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Chris" == Chris Moller <cmoller@redhat.com> writes:

Chris> [Question: Internally, this patch is based on "sizeof" which actually
Chris> creates an int type that, in addition to just being printed, can be
Chris> used for stuff like "set <var> = sizeof(<whatever>)".  The gdb typeid
Chris> doesn't even try to create an analogue to a type_info class, it just
Chris> extracts the name from the appropriate type struct and creates a
Chris> cstring type from it.  Would it be good/essential for the
Chris> implementation to instantiate a real type_info class?  (That, I
Chris> suspect, will be a lot more work...)]

I think it is reasonably important to find the type_info.  Anything else
will yield results which violate the "cut and paste" rule.  E.g., the
user might have a function that takes a `const type_info&' argument.

It may be reasonable to require the user to have libstdc++ debuginfo
installed in order for this to work.  I would accept this as a first
patch (with the usual caveat that if new information arises, etc).

IIRC, the type_info object is stored in some vtable slot in the v3 ABI.
If that is in fact the case then we probably want a new cp-abi function
for this.  In this situation, IMO it is ok for the v2 variant to throw
an exception (or not be implemented, same difference).

One additional possible gotcha is making sure that gdb gives a sensible
error message if the user compiled with -fno-rtti.

Chris> +    {"typeid", TYPEID, OP_NULL, 0},

This is a C++ keyword, so the last field should be 1, not 0.

Chris> +static struct value *evaluate_subexp_for_typeid_type (struct expression *, int *);
Chris> +static struct value *evaluate_subexp_for_typeid_var (struct expression *, int *);

The new style is to put static functions above their uses so we don't
have to have forward declarations.

Tom