This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfc/cp] method stub assertions
On Sun, Jan 04, 2004 at 07:50:48PM -0500, Michael Chastain wrote:
> I'm working on support for hp-ux aCC.
>
> When I call a C++ method, I get this assertion failure:
>
> call class_param.Aptr_a (&g_A)
> /house/chastain/gdb/s1/gdb/valops.c:1942: internal-error: Assertion `TYPE_DOMAIN_TYPE (fns_ptr[0].type) != NULL' failed.
>
> This assertion is in find_overload_method:
>
> /* If we are dealing with stub method types, they should have
> been resolved by find_method_list via value_find_oload_method_list
> above. */
> gdb_assert (TYPE_DOMAIN_TYPE (fns_ptr[0].type) != NULL);
>
> The "domain type" is a pointer from the method to the base class
> that defines the virtual table for the class that contains this method.
>
> Here is some history about this assertion:
>
> http://sources.redhat.com/ml/gdb-patches/2002-05/msg00413.html
>
> Unfortunately, hpread.c does not set TYPE_DOMAIN_TYPE. As far as I can
> tell, only dwarf2read.c and stabsread.c set this field.
No, that's not correct. hpread.c sets it the same way that
dwarf2read.c does, by calling smash_to_method_type and
smash_to_member_type.
These are only used in hpread for DNTT_TYPE_PTRMEMFUNC and
DNTT_TYPE_PTRMEM.
dwarf2read, however, calls smash_to_method_type when creating a method
type.
> Fortunately, it appears that TYPE_DOMAIN_TYPE is really only needed for
> calls through member pointers or member function pointers. Such calls
> are forbidden with hp-ux som anyways.
>
> This patch adjusts some asserts. I want to change find_overload_method
> so that the code asserts that methods are not stubbed (which is what it
> really needs), and then change evaluate_subexp_standard so that it
> asserts TYPE_DOMAIN_TYPE when it really uses them.
Right now we assume that methods have a TYPE_DOMAIN_TYPE. This patch
pushes more knowledge of limited debug readers out into the rest of
GDB. I'd rather go the other direction - set a domain type. If I'm
reading dwarf2read correctly it simply uses the enclosing class, not
walking back to find the class containing the vtable as you describe
above. It's for _classes_ that it behaves as described above. See the
comment:
/* For types with virtual functions (TYPE_CODE_STRUCT), VPTR_BASETYPE
is the base class which defined the virtual function table pointer.
For types that are pointer to member types (TYPE_CODE_MEMBER),
VPTR_BASETYPE is the type that this pointer is a member of.
For method types (TYPE_CODE_METHOD), VPTR_BASETYPE is the aggregate
type that contains the method.
Unused otherwise. */
> After I do this, gdb gets further, but then crashes anyways in:
>
> evaluate_subexp_standard
> find_overload_match
> value_virtual_fn_field
> gnuv2_virtual_fn_field # WRONG!
> value_primitive_field
> check_typedef
>
> So the next problem after this is that the the abi type is set to
> gnu-v2. When I do "set cp-abi hpaCC", gdb calls the function,
> although I see further problems after that.
You will need to find some way to autodetect this. Does aCC still
produce SOM output, even for hppa64? If so you can use
hp_som_object_present, but that's a gross hack. It would be better to
find another way.
See where we autodetect gnu_v3.
> Anyways, my questions are:
>
> Am I on the right track?
> Can I commit this?
No, please try to set TYPE_DOMAIN_TYPE in hpread instead. I think
around line 3950 is the only place you'll need to. Hmm... or perhaps
calling smash_to_method_type at 3861. That may work.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer