On Tuesday, June 3, 2025, Thiago Macieira wrote:

>
> You're missing the fact that on the ARM64e architecture with authenticated
> pointers, the vtable entry in the class does not contain a pointer. It
> contains an encrypted datum that, when passed to the instruction in
> question
> with some extra information (an integer) is decrypted by the hardware into
> a
> pointer. Therefore, you must known this extra information and, as Oliver
> has
> repeatedly pointed out, it's different from class to class. Therefore, you
> CANNOT decrypt it unless you know what class that was supposed to point
> to,
> just as you cannot load the pointer with MSVC without knowing what offset
> from
> the top of the object it was supposed to be at.
>



Hmm . . . the plot thickens. I think I have a better understanding now
though of how it all works, and I can see why Oliver was getting a little
frustrated with me for not catching on sooner.

So . . . . before the type-erasure takes place, we would have to record
this secret number somewhere. This recording would happen inside the
constructor of 'std::polyhandle':

    template<class Tref> requires is_polymorphic_v< remove_cvref_t<Tref> >
    polyhandle::polyhandle(Tref &&obj) noexcept
    {
        typedef remove_cvref_t<Tref> T;
        this->p = addressof(obj);
        // ... and also record the secret number
    }

Broadly speaking there are two ways of recording the secret number:

    (1) Increase the size of 'polyhandle' from 8 bytes to 10 bytes
(because it looks in Oliver's assembler as though the secret number is
16-Bit)

    (2) Keep 'polyhandle' the same size but populate a global map that maps
the encrypted datum to the secret number. Set this map to be a constant 1
megabyte in size and you won't have any problems with dynamic allocation. 1
megabyte would accommodate 104 thousand classes. Maybe it can be made
lockfree too for multi-threading.

Possibility No. 1 would mean an ABI break from using a ' void * ' however
it would not exclude new Apple computers from using this new 'polyhandle'
feature.

Possibility No. 2 would mean that a 'polyhandle' is ABI-compatible with a '
void * ', and there would just be a little overhead in accessing the global
map. But again, new Apple computers would be able to use 'polyhandle'.

I think I'll build an aarch64 cross-compiler to run on my x86_64 computer
and put it inside a chroot jail with Qemu and see about getting Possibility
No. 2 working.