Hello,
I'd just like to inquire about the status of the MSVC compatible RTTI implementation, when it might be complete and how I can keep track of progress on this feature.
Thanks very much,
Kim
would be great to have an place for related information to keep track of the progress
ABI
(PDB-Support?)
etc.
Among all those I know of working on the MS ABI compatibility, none have made RTTI an immediate priority. Personally, I’ve made progress understanding some of the subtleties of the format. However, I’ve put this work on my back-burner because it requires changes to LLVM IR itself.
In general, ABI compatibility is most easily achieved when IR constructs are able to already represent ABI constructs.
I don’t think it would be unreasonable for us to maintain a list of things we do and do not claim to support.
I don't think it would be unreasonable
for us to maintain a list of things
we do and do not claim to support.
that would be perfect
a very simple page (maybe a clang llvm.org subpage, or something like a single wikipage somewhere so others can extend)
with information about what would bee needed for full 100% MSVC compatibility
like super tiny sections about ABI, RTTI, SEH(64), PDB, etc. with
information behind what is the current state (maybe the silly percent, beginning, nearly-ready, done..., ignored, etc.)
would be absolutely great to make other people understand whats still missing to just work out of
the box and to reduce frustrating tryouts with no success/chance to work
FWIW, MSVC's RTTI implementation has one nice property (which I'd like if Clang could also 'emulate'): it (dynamic_cast) does not crash on objects w/o an RTTI record (while Clang under OSX always crashed for me in those cases).
Such a case, for example, often arises if you use a (lame) GUI library which requires RTTI (because it relies on dynamic_cast and cross-casting) so you enable RTTI for its sources but disable it for others/your own sources (in order to minimize bloat and the leaking of internal implementation details as plain text in the final binary). Then when the GUI lib calls dynamic_cast on one of your own objects (because you, for example, added it to some widget container) it will simply get a nullptr result with MSVC (while, as I mentioned, you'll get a crash with Clang)...
I don't think it would be unreasonable for us to maintain a list of
things we do
and do not claim to support.FWIW, MSVC's RTTI implementation has one nice property (which I'd like if
Clang could also 'emulate'): it (dynamic_cast) does not crash on objects
w/o an RTTI record (while Clang under OSX always crashed for me in those
cases).
Such a case, for example, often arises if you use a (lame) GUI library
which requires RTTI (because it relies on dynamic_cast and cross-casting)
so you enable RTTI for its sources but disable it for others/your own
sources (in order to minimize bloat and the leaking of internal
implementation details as plain text in the final binary). Then when the
GUI lib calls dynamic_cast on one of your own objects (because you, for
example, added it to some widget container) it will simply get a nullptr
result with MSVC (while, as I mentioned, you'll get a crash with Clang)...
Are you suggesting Clang crashes, or Clang produces a program that crashes?
In any case, I don't think either would be intended - you should either get
a compile-time error (because the type isn't dynamic) or a runtime check
(null or non-null, not a crash).
I don't think it would be unreasonable
for us to maintain a list of things
we do and do not claim to support.that would be perfect
a very simple page (maybe a clang llvm.org subpage, or something like a
single wikipage somewhere so others can extend)
with information about what would bee needed for full 100% MSVC
compatibility
like super tiny sections about ABI, RTTI, SEH(64), PDB, etc. with
information behind what is the current state (maybe the silly percent,
beginning, nearly-ready, done..., ignored, etc.)
Could someone in the know about our compatibility status start up
docs/MSVCCompat.rst?
If unfamiliar with Sphinx/reST this may help: <
http://llvm.org/docs/SphinxQuickstartTemplate.html>
-- Sean Silva
Are you suggesting Clang crashes, or Clang produces a program that crashes?
Clang produces a program that crashes.
In any case, I don't think either would be intended - you should either get a
compile-time error (because the type isn't dynamic) or a runtime check (null or
non-null, not a crash).
Perhaps the culprit isn't Clang but simply in the (RTTI) ABI and/or the implementation of dynamic_cast in libstdc++ (the old one in OSX)...
The problem basically appears if you have a polymorphic type in a TU compiled with -fno-rtti and you pass a pointer to such an object to a function in a TU compiled with -frtti which calls dynamic_cast on it...
The code that actually performs the dynamic_cast is not actually emitted by the compiler. The behavior you are seeing is not coming from the compiler but from the __RTDynamicCast function.
Clang’s job is to call __RTDynamicCast with the correct arguments, nothing more.
The Itanium ABI, utilized by OS X and Linux, specifies that this cast is performed by __dynamic_cast. Again, all we do is provide the necessary argument to this function and let the underlying runtime do the rest.
This behavior is not really up to us to emulate.
Also note that the ability to handle these kinds of memory exceptions happens under the aegis of SEH, making an already heavyweight operation even heavier.
I noticed yesterday that we don't warn on use of dynamic_cast compiling with -fno-rtti. While it can work if you are dynamic_casting a class from another compilation unit that is compiled with RTTI, there's a good chance that you're compiling most of your code with the same RTTI settings, so having a warning would be nice - users can always turn it off if they're sure that what they're doing is safe.
It would be really nice if you could turn RTTI generation on and off on specific classes (and have the setting propagated to inherited classes). I'm working on some code where subclasses of exactly one class want to do dynamic_cast, and rather than implementing an ad-hoc RTTI-like mechanism, it would be great to just set an attribute saying '[indirect] subclasses of this class must have RTTI generated, even if the global setting is not'.
David
And what library implements __dynamic_cast for clang on Linux/OS X?
libsupc++, libc++abi, or libcxxrt, depending on your particular configuration.
One of these may be statically linked into libstdc++ / libc++.
David
Yes, that'd be great...I pondered such ideas ever since I came across MSVC's __declspec( novtable ) (which Clang still does not support)...
In fact I consider it a language defect: there should be a standardized way to turn RTTI on or off on a per class and per hierarchy basis...
So, it took me a while, but I wrote some docs on Clang compatibility with MSVC:
http://clang.llvm.org/docs/MSVCCompatibility.html
This is awesome - thanks so much!
thats great thank you so much
Thanks!