I would agree with Brian and others who have said this, but this is getting a bit spammy.
The constant updates flooded with small details about the internal working of the Microsoft ABI can be interesting, but I do not think this mailing list is the correct place for it. A blog post would be more suitable.

As Brian said, I think the why is far more important than the how, especially because compiler vendors will most likely be able to implement all of this on their own.

Sincerely,

Op wo 17 apr 2024 om 11:37 schreef Frederick Virchanza Gotham via Std-Proposals <std-proposals@lists.isocpp.org>:
On Wed, Apr 17, 2024 at 12:07 AM Thiago wrote:
>
> > If you use Visual Studio 2022 to build your program as x86_32, then
> > they are just normal 32-Bit pointers. However if you build your
> > program as x86_64, then they are 32-Bit offsets which you add to the
> > return address from "GetModuleHandleA(nullptr)".
>
> I see. So can they point to structures found in dllimport'ed libraries? Well,
> they can't, so how the hell can dynamic_cast cast across DLLs?


    struct RTTICompleteObjectLocator {
        unsigned long signature;
        unsigned long offset;
        unsigned long cdOffset;
        int           pTypeDescriptor;
        int           pClassDescriptor;
        int           pSelf;
    };

The last member of the struct, "pSelf", is the 32-Bit offset from the
module's base address to the current "RTTICompleteObjectLocator"
object. So in order to get the module's base address, you do:

    void *module = (char*)&locator - locator.pSelf;

Presumably that's what Microsoft uses to throw exceptions from DLL's
to EXE's on x86_64 computers.

I'm very close to having __RTDynamicCast reverse-engineered to find
the ThrowInfo. All the structs are nicely described here:
https://www.lukaszlipski.dev/post/rtti-msvc/
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals


--
Rhidian De Wit
Software Engineer - Barco