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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
