[llvm-dev] RuntimeDyLdCOFF and RTTI on Windows

Thu Oct 6 17:29:07 PDT 2016

HI Stefan,

CC'ing Reid Kleckner, who might have some insight here, and llvm-dev as
this may be of interest to other windows JIT users.

I am facing the issue that C++ dynamic_cast doesn't work for types
> loaded from object files with RuntimeDyLd.

<snip>

Do you think it is possible that RuntimeDyLd misses type info data in
> the COFF file or doesn't wire it up correctly?
> I set ProcessAllSections = true, but I didn't recognize any change. I
> found that RuntimeDyLdCOFF does not override finalizeLoad like the ELF
> and MachO versions. The function call's comment reads "Give the
> subclasses a chance to tie-up any loose ends" -- possibly missing
> functionality?
>

Unfortunately I don't have a windows machine to test on, so it's difficult
to know for sure. From a quick look at the IR, it seems like the Window's
C++ ABI implementation of dynamic_cast works similarly to Darwin's: The
type info pointers for the reference type and cast type are passed in to
the function, so as long as memory has been allocated for the type info I
would have expected this to "just work". My best guess for why it wouldn't
is that RuntimeDyldCOFF is a missing relocation somewhere. What happens
when you run this code on a debug build? Do you hit the llvm_unreachable at
the bottom of the resolveRelocation switch?

Just to rule out one other possibility, Reid: does Windows require any
special calls to register C++ RTTI?

Finally, regarding the ProcessAllSections flag: it tells RuntimeDyld to
call the memory manager interface for every section, not just the sections
that RuntimeDyld thinks are necessary for execution. This was a hack to
make debug info sections visible to clients who are interested in them. It
can be important if your object file contains metadata sections that are
required, but not referenced in the file. I don't think it should affect
this case though.

- Lang.

On Thu, Oct 6, 2016 at 4:37 AM, Stefan Gränitz <stefan.granitz at roli.com>
wrote:

> Hi Lang
>
> You are not only the maintainer for ORC but also for RuntimeDyLd right?
> May I ask if you know about problems reading RTTI data from COFF object
> files on Windows?
>
> I am facing the issue that C++ dynamic_cast doesn't work for types
> loaded from object files with RuntimeDyLd. I inspected my object files
> compiled with Clang-3.9 (pure, not cl2) and they seem to include all the
> necessary info. When I link (with MS link) and run the static build I
> get the expected behavior. Correspondingly I'd consider the RTTI
> emission in Clang to work correctly.
>
> When I load the object files with RuntimeDyLd at runtime, I face the
> following troubles in vcruntime140.dll:
> * invoking dynamic_cast: the RTTI Complete Object Locator queried in
> __RTDynamicCast (rtti.cpp) has incomplete data, which tricks the runtime
> to always belief the number of base classes is zero, that's why
> dynamic_cast never succeeds
> * invoking typeid(variable).name(): the runtime's __std_type_info_name
> (std_type_info.cpp) receives a corrupt type data pointer, which causes
> an access violation when reading from one of its members
>
> Do you think it is possible that RuntimeDyLd misses type info data in
> the COFF file or doesn't wire it up correctly?
> I set ProcessAllSections = true, but I didn't recognize any change. I
> found that RuntimeDyLdCOFF does not override finalizeLoad like the ELF
> and MachO versions. The function call's comment reads "Give the
> subclasses a chance to tie-up any loose ends" -- possibly missing
> functionality?
>
> It would help a lot if you let me know your feeling on this issue and/or
> give me a few pointers what I could check next.
>
> I can reproduce the above symptoms reliably within our project on
> different Windows systems. I think I can also prepare a self-contained
> repro, if you happen to have a Windows machine/VM at hand and you are
> interested in clearing up this issue.
>
> Thanks.
> Stefan
>
> --
> Stefan Gränitz
> Consultant Software Development JUCE
>
>
> --
>
>
> *ROLI* <http://www.roli.com/>* extends the journey of music creation to
> everyone. The **acclaimed * <http://www.roli.com/press/reviews>*Seaboard
> GRAND* <http://www.roli.com/products/seaboard-grand>* and **Seaboard RISE*
> <http://www.roli.com/products/seaboard-rise>* redefine how expressive and
> versatile an electronic musical instrument can be. Our groundbreaking
> software **Equator* <http://www.roli.com/equator>* opens up new dimensions
> of sonic expression, and is built with **JUCE* <http://www.juce.com/>*,
> ROLI’s proprietary coding platform, and the leading C++ framework for audio
> applications globally. **Blend* <http://www.blend.io/>* enables everyone
> to
> seamlessly collaborate, share, and remix their music. And **NOISE*
> <http://www.roli.com/noise>* is the most expressive app ever made — see
> for
> yourself: **download it now for free!
> <https://itunes.apple.com/app/noise-5d/id1011132019?ls=1&mt=8>*
>
>
> Office: +44(0)207 254 2155
>
> *ROLI*
>
> 2 Glebe Road, London E8 4BD
>
> www.roli.com
>
>
>
> Discover more about us on Facebook <http://www.facebook.com/roli> -
> Twitter
> <http://www.twitter.com/weareroli> - Youtube
> <http://www.youtube.com/weareroli>
>
> ROLI Ltd. is a registered company in England and Wales, and this e-mail and
> its attachment(s) are intended for the above named only and are
> confidential. If they have come to you in error then you must take no
> action based upon them but contact us immediately. Any disclosure, copying,
> distribution or any action taken or omitted to be taken in reliance on it
> is prohibited and may be unlawful. Although this e-mail and its attachments
> are believed to be free of any virus, it is the responsibility of the
> recipient to ensure that they are virus free. If you contact us by e-mail
> then we will store your name and address to facilitate communications. Any
> statements contained herein are those of the individual and not the
> organisation.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161006/19217e1c/attachment.html>