[PATCH] D43184: [WIP] [ItaniunCXXABI] Add an option for loading the type info vtable with dllimport

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo added a comment.

In https://reviews.llvm.org/D43184#1039278, @rnk wrote:

> 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.


Yes - it's only unannotated data imports that is the issue.

> 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.

True, that would avoid the really bad cases - and since a reference to that isn't embedded in instructions in the text segments, the existing plain pointer fixups should suffice.

>> 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.

Ok - I'll put it on the backburner, and maybe see if I'd try implementing the linker part of fixing unannotated data imports at some point.

>> 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.

Ok, thanks.


Repository:
  rC Clang

https://reviews.llvm.org/D43184