Re: [rfc/cp] method stub assertions

[Daniel Jacobowitz <drow@mvista.com>]

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