[PATCH] D43184: [WIP] [ItaniunCXXABI] Add an option for loading the type info vtable with dllimport
Reid Kleckner via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Thu Mar 15 11:55:31 PDT 2018
rnk added a comment.
In https://reviews.llvm.org/D43184#1038396, @mstorsjo wrote:
> (Accidentally pressed submit too soon)
> This was my conclusion at some point as well - but there's also a few issues with that approach which makes me quite hesitant:
> - doing fixups in the code segment requires making it writable temporarily at runtime, which is disallowed in UWP
> - the current set of runtime relocations only allows adding addresses in 1, 2, 4 and 8 byte sized addresses. On arm/arm64, absolute addresses can be present in instructions with a much more complicated opcode format, and tweaking addresses there requires defining more runtime relocation formats.
I wouldn't consider relocating non-dllimport references to dllimport symbols as being in scope. As long the symbol is annotated as dllimport, the compiler will generate code that does a load from the __imp_ pointer in the IAT.
For unannotated symbols, the linker already generates thunks for function references, so that just leaves data imports.
Still, the RTTI will be in the .rdata section, so it will require unprotecting readonly memory, which won't work in UWP. We could move it to .data, I guess.
> So given all this - I only see bad options. I could just postpone this as well - I can live with only linking libc++ statically for now.
Might be the thing to do.
> The other case you mentioned, with multiple inheritance for statically allocated objects, needs to be handled in one way or another though (unless one forbids C++ interfaces over DLL boundaries); how's that handled with the MSVC C++ ABI?
I think local vftables handle it.
More information about the cfe-commits