Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Wu Zhou <woodzltc@cn.ibm.com>
To: drow@false.org, gdb-patches@sources.redhat.com
Subject: [PatchPing]: Remove the dependence of TYPE_VPTR_FIELDNO to find vptr
Date: Tue, 22 Nov 2005 17:14:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.63.0511221403350.31199@linux.site> (raw)
In-Reply-To: <Pine.LNX.4.63.0510211754001.20690@linux.site>

Hi Daniel,

Do you think that this patch still make sense provided that Elena had 
checked in my patch to add XL compiler specific code to set 
TYPE_VPTR_FIELDNO and TYPE_VPTR_BASETYPE?

Maybe we can at lease keep virtual base type non-zero checking before 
accessing its members (such as TYPE_VPTR_FIELDNO)?

Sincerely looking forward to your reply.

Regards
- Wu Zhou

On Fri, 21 Oct 2005, Wu Zhou wrote:

> Hi Daniel,
> 
> As we discussed a few days ago, in gnu-v3-abi.c we can skip all the 
> rigamarole with the debuginfo to directly find the VPTR, which is always 
> at offset 0 of the struct.  So if the c++ compiler don't depend on 
> DW_AT_containing_type and don't set TYPE_VPTR_FIELDNO, we can use 
> that rule to directly get the address of VPTR.  I had thought of 
> removing TYPE_VPTR_FIELDNO completely in gnu-v3-abi.c, but found that 
> gnuv3_rtti_type need to look into TYPE_VPTR_FIELDNO to determine whether 
> we can find the RTTI.  So before we can find an alternative way to 
> replace that (do you have any thought on how to do that?), we still need 
> TYPE_VPTR_FIELDNO. 
> 
> So I am now adopting the following method: if TYPE_VPTR_BASETYPE is zero, 
> we skip these code to check and fill TYPE_VPTR_FIELDNO.  And I will use 
> the following code to find the VPTR:
> 
>   vtable_address = unpack_long (builtin_type_void_data_ptr, value_contents (value));
> 
> I had coded a patch and tested it on x86, ppc32 and ppc64.  No regression 
> was found with the c++ testcases.  Do you think this method is 
> acceptable?  Appended is the patch.  Please review and comment.
> 
> 2005-10-21  Wu Zhou  <woodzltc@cn.ibm.com>
> 
> 	* gnu-v3-abi.c (gnuv3_rtti_type): Before getting the fieldno,
> 	check the type is not NULL.  The vptr is always at the offset
> 	0 of the struct,  use this knowledge to find it.
> 	* gnu-v3-abi.c (gnuv3_virtual_fn_field): Ditto.
> 	* gnu-v3-abi.c (gnuv3_baseclass_offset): Before getting the
> 	fieldno, check the type is not NULL.
> 
> Index: gnu-v3-abi.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/gnu-v3-abi.c,v
> retrieving revision 1.28
> diff -c -3 -p -r1.28 gnu-v3-abi.c
> *** gnu-v3-abi.c	12 May 2005 15:28:31 -0000	1.28
> --- gnu-v3-abi.c	21 Oct 2005 09:47:54 -0000
> *************** gnuv3_rtti_type (struct value *value,
> *** 217,230 ****
>     /* Fetch VALUE's virtual table pointer, and tweak it to point at
>        an instance of our imaginary gdb_gnu_v3_abi_vtable structure.  */
>     base_type = check_typedef (TYPE_VPTR_BASETYPE (values_type));
> !   if (values_type != base_type)
>       {
>         value = value_cast (base_type, value);
>         if (using_enc_p)
>   	*using_enc_p = 1;
>       }
> !   vtable_address
> !     = value_as_address (value_field (value, TYPE_VPTR_FIELDNO (values_type)));
>     vtable = value_at_lazy (vtable_type,
>                             vtable_address - vtable_address_point_offset ());
>     
> --- 217,231 ----
>     /* Fetch VALUE's virtual table pointer, and tweak it to point at
>        an instance of our imaginary gdb_gnu_v3_abi_vtable structure.  */
>     base_type = check_typedef (TYPE_VPTR_BASETYPE (values_type));
> !   if (base_type && values_type != base_type)
>       {
>         value = value_cast (base_type, value);
>         if (using_enc_p)
>   	*using_enc_p = 1;
>       }
> ! 
> !   vtable_address = unpack_long (builtin_type_void_data_ptr,
> ! 				value_contents (value));
>     vtable = value_at_lazy (vtable_type,
>                             vtable_address - vtable_address_point_offset ());
>     
> *************** gnuv3_virtual_fn_field (struct value **v
> *** 305,320 ****
>     /* This type may have been defined before its virtual function table
>        was.  If so, fill in the virtual function table entry for the
>        type now.  */
> !   if (TYPE_VPTR_FIELDNO (vfn_base) < 0)
>       fill_in_vptr_fieldno (vfn_base);
> !   if (TYPE_VPTR_FIELDNO (vfn_base) < 0)
>       error (_("Could not find virtual table pointer for class \"%s\"."),
>   	   TYPE_TAG_NAME (vfn_base) ? TYPE_TAG_NAME (vfn_base) : "<unknown>");
>   
>     /* Now that we know which base class is defining our virtual
>        function, cast our value to that baseclass.  This takes care of
>        any necessary `this' adjustments.  */
> !   if (vfn_base != values_type)
>       value = value_cast (vfn_base, value);
>   
>     /* Now value is an object of the appropriate base type.  Fetch its
> --- 306,322 ----
>     /* This type may have been defined before its virtual function table
>        was.  If so, fill in the virtual function table entry for the
>        type now.  */
> ! 
> !   if (vfn_base && TYPE_VPTR_FIELDNO (vfn_base) < 0)
>       fill_in_vptr_fieldno (vfn_base);
> !   if (vfn_base && TYPE_VPTR_FIELDNO (vfn_base) < 0)
>       error (_("Could not find virtual table pointer for class \"%s\"."),
>   	   TYPE_TAG_NAME (vfn_base) ? TYPE_TAG_NAME (vfn_base) : "<unknown>");
>   
>     /* Now that we know which base class is defining our virtual
>        function, cast our value to that baseclass.  This takes care of
>        any necessary `this' adjustments.  */
> !   if (vfn_base && vfn_base != values_type)
>       value = value_cast (vfn_base, value);
>   
>     /* Now value is an object of the appropriate base type.  Fetch its
> *************** gnuv3_virtual_fn_field (struct value **v
> *** 323,333 ****
>        Does multiple inheritance affect this?
>        Can this even trigger, or is TYPE_VPTR_BASETYPE idempotent?
>     */
> !   if (TYPE_VPTR_BASETYPE (vfn_base) != vfn_base)
>       value = value_cast (TYPE_VPTR_BASETYPE (vfn_base), value);
> -   vtable_address
> -     = value_as_address (value_field (value, TYPE_VPTR_FIELDNO (vfn_base)));
>   
>     vtable = value_at_lazy (vtable_type,
>                             vtable_address - vtable_address_point_offset ());
>   
> --- 325,336 ----
>        Does multiple inheritance affect this?
>        Can this even trigger, or is TYPE_VPTR_BASETYPE idempotent?
>     */
> !   if (TYPE_VPTR_BASETYPE (vfn_base) && 
> !       TYPE_VPTR_BASETYPE (vfn_base) != vfn_base)
>       value = value_cast (TYPE_VPTR_BASETYPE (vfn_base), value);
>   
> +   vtable_address = unpack_long (builtin_type_void_data_ptr,
> + 				value_contents (value));
>     vtable = value_at_lazy (vtable_type,
>                             vtable_address - vtable_address_point_offset ());
>   
> *************** gnuv3_baseclass_offset (struct type *typ
> *** 398,407 ****
>        we have debugging information for that baseclass.  */
>   
>     vbasetype = TYPE_VPTR_BASETYPE (type);
> !   if (TYPE_VPTR_FIELDNO (vbasetype) < 0)
>       fill_in_vptr_fieldno (vbasetype);
>   
> !   if (TYPE_VPTR_FIELDNO (vbasetype) >= 0
>         && TYPE_FIELD_BITPOS (vbasetype, TYPE_VPTR_FIELDNO (vbasetype)) != 0)
>       error (_("Illegal vptr offset in class %s"),
>   	   TYPE_NAME (vbasetype) ? TYPE_NAME (vbasetype) : "<unknown>");
> --- 401,410 ----
>        we have debugging information for that baseclass.  */
>   
>     vbasetype = TYPE_VPTR_BASETYPE (type);
> !   if (vbasetype && TYPE_VPTR_FIELDNO (vbasetype) < 0)
>       fill_in_vptr_fieldno (vbasetype);
>   
> !   if (vbasetype && TYPE_VPTR_FIELDNO (vbasetype) >= 0
>         && TYPE_FIELD_BITPOS (vbasetype, TYPE_VPTR_FIELDNO (vbasetype)) != 0)
>       error (_("Illegal vptr offset in class %s"),
>   	   TYPE_NAME (vbasetype) ? TYPE_NAME (vbasetype) : "<unknown>");
> 
> 
> Best Regards
> - Wu Zhou
> 


      reply	other threads:[~2005-11-22 16:06 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-21 10:14 [RFC/gnu-v3-abi]: " Wu Zhou
2005-11-22 17:14 ` Wu Zhou [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.63.0511221403350.31199@linux.site \
    --to=woodzltc@cn.ibm.com \
    --cc=drow@false.org \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox