Managed to get it working with:
tree index = build_int_cst (NULL_TREE,
-2 * TARGET_VTABLE_DATA_ENTRY_DISTANCE);
tree src_vptr = build_address(build_vtbl_ref(src_obj, index));
tree trgt_vtbl_decl = get_vtable_decl(target_type, 0);
tree trgt_vtbl_addr = build_address(trgt_vtbl_decl);
________________________________
From: Thomas de Bock
Sent: 07 July 2025 16:05:17
To: [email protected]
Subject: Offset vtable address
Currently working with the C++-frontend, I am trying to compare the addresses
of the "trgt" (originally a type) and "src" (originally a class instance)
vtables.
Currently I am successfully retrieving the vptr value of the src instance at
runtime, and the vtable address of the trgt at compiletime, with the following
code:
tree src_vptr = build_vfield_ref(src_obj, TREE_TYPE(src_obj));
tree trgt_vtbl_decl = get_vtable_decl(target_type, 0);
// Gives actual vtable address, vptr does not (offsetted by RTTI and
offset-to-top)
tree trgt_vtbl_addr = build_address(trgt_vtbl_decl);
However, as the comment suggests, this is not satisfactory: Due to the way the
vptr is offsetted by the offset-to-top and RTTI ptr, they differ by 0x10 bytes.
Not wanting to just offset by a hardcoded amount, I tried to adjust for this by
getting the DECL_INITIAL of the trgt_vtbl_decl then trying to get the
decleration at index 2 from the CONSTRUCTOR_ELTS, but this resulted in strange
values.
Is there anyone that knows how I can account for this offset using the c++
frontend API, is just hardcoding the offset to be 2 pointers fine too?
Hoping to get it merged, so dedicated to following proper convention, any help
very much appreciated, thank you.
This e-mail and any attachments may contain information that is confidential
and proprietary and otherwise protected from disclosure. If you are not the
intended recipient of this e-mail, do not read, duplicate or redistribute it by
any means. Please immediately delete it and any attachments and notify the
sender that you have received it by mistake. Unintended recipients are
prohibited from taking action on the basis of information in this e-mail or any
attachments. The DRW Companies make no representations that this e-mail or any
attachments are free of computer viruses or other defects.
