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

Wed Mar 14 22:45:15 PDT 2018

mstorsjo added a comment.

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

> In https://reviews.llvm.org/D43184#1031831, @mstorsjo wrote:
>
> > So in case this approach as my hacky PoC does is the only feasible way left, I obviously need to fix it up. Any directions and suggestions on how to structure it properly? And suggestions for the user visible option, etc?
>
>
> Well, I guess it's the equivalent of /MD /MT, i.e. is your CRT static or dynamic. How is this expressed to GCC?

I don't think they really have any equivalent; on mingw, the CRT itself can only be linked dynamically, and for things like libstdc++, it follows the `-static` flag (i.e. normally looks for libs named `libX.dll.a`, and if not found or if `-static` is specified, looks for `libX.a`). But `-static` is a linker flag only so it doesn't help for deciding what to emit at compile time.

>> Actually, it feels like that blogpost is rather outdated; I can't manage to make current binutils produce this form of fixups for the issue at all. What it does however, is create a runtime pseudo relocation; the linker generates extra info in the rdata section about the relocations it wasn't able to handle, which the mingw crt will fix up on startup before handing control over to the end user code. This can involve changing the protection of the code sections to writeable in order to do such fixups there. (This feature has been in binutils since 2002.)
> 
> So basically mingw has a custom relocation format layered on top of PE. I mean, that would certainly help code size. Otherwise, every TU that emits a vtable with RTTI is going to need a dynamic initializer... that would be bad for startup time, unless we have clever ways to dedupe them across TUs.
> 
> Maybe the cleaner thing to do is to actually handle this as a relocation. I tried to figure out what GCC is doing, but it doesn't seem to work at all.

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

Repository:
  rC Clang

https://reviews.llvm.org/D43184