<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Thanks Lang for forwarding this to the list<br>
The symptom in a nutshell: I cannot get dynamic_cast to work in
JITed code on Windows<br>
<br>
Reid, do you have an idea whether: it's a bug / it's just not
implemented yet / I am missing something?<br>
<blockquote type="cite">
<div>Just to rule out one other possibility, Reid: does Windows
require any special calls to register C++ RTTI?<br>
</div>
</blockquote>
<br>
There's some more details in the original mail.<br>
<br>
Thanks<br>
Stefan<br>
<br>
<div class="moz-cite-prefix">Am 07.10.16 um 02:29 schrieb Lang Hames
via llvm-dev:<br>
</div>
<blockquote
cite="mid:CALLttgoCdQsiwEMjcC8yJQVv84Y_JPwC884bC6TaT-uJ-Lq6Ew@mail.gmail.com"
type="cite">
<div dir="ltr">HI Stefan,
<div><br>
</div>
<div>CC'ing Reid Kleckner, who might have some insight here, and
llvm-dev as this may be of interest to other windows JIT
users.</div>
<div><br>
</div>
<div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span
style="font-size:12.800000190734863px">I am facing the
issue that C++ dynamic_cast doesn't work for types<br>
</span><span style="font-size:12.800000190734863px">loaded
from object files with RuntimeDyLd.</span></blockquote>
<div> </div>
<div><snip></div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span
style="font-size:12.800000190734863px">Do you think it is
possible that RuntimeDyLd misses type info data in</span><br
style="font-size:12.800000190734863px">
<span style="font-size:12.800000190734863px">the COFF file
or doesn't wire it up correctly?</span><br
style="font-size:12.800000190734863px">
<span style="font-size:12.800000190734863px">I set
ProcessAllSections = true, but I didn't recognize any
change. I</span><br style="font-size:12.800000190734863px">
<span style="font-size:12.800000190734863px">found that
RuntimeDyLdCOFF does not override finalizeLoad like the
ELF</span><br style="font-size:12.800000190734863px">
<span style="font-size:12.800000190734863px">and MachO
versions. The function call's comment reads "Give the</span><br
style="font-size:12.800000190734863px">
<span style="font-size:12.800000190734863px">subclasses a
chance to tie-up any loose ends" -- possibly missing</span><br
style="font-size:12.800000190734863px">
<span style="font-size:12.800000190734863px">functionality?</span><br>
</blockquote>
<div><br>
</div>
</div>
<div>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?</div>
<div><br>
</div>
<div>Just to rule out one other possibility, Reid: does Windows
require any special calls to register C++ RTTI?</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>- Lang.</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Oct 6, 2016 at 4:37 AM, Stefan
Gränitz <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:stefan.granitz@roli.com" target="_blank">stefan.granitz@roli.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Lang<br>
<br>
You are not only the maintainer for ORC but also for
RuntimeDyLd right?<br>
May I ask if you know about problems reading RTTI data from
COFF object<br>
files on Windows?<br>
<br>
I am facing the issue that C++ dynamic_cast doesn't work for
types<br>
loaded from object files with RuntimeDyLd. I inspected my
object files<br>
compiled with Clang-3.9 (pure, not cl2) and they seem to
include all the<br>
necessary info. When I link (with MS link) and run the
static build I<br>
get the expected behavior. Correspondingly I'd consider the
RTTI<br>
emission in Clang to work correctly.<br>
<br>
When I load the object files with RuntimeDyLd at runtime, I
face the<br>
following troubles in vcruntime140.dll:<br>
* invoking dynamic_cast: the RTTI Complete Object Locator
queried in<br>
__RTDynamicCast (rtti.cpp) has incomplete data, which tricks
the runtime<br>
to always belief the number of base classes is zero, that's
why<br>
dynamic_cast never succeeds<br>
* invoking typeid(variable).name(): the runtime's
__std_type_info_name<br>
(std_type_info.cpp) receives a corrupt type data pointer,
which causes<br>
an access violation when reading from one of its members<br>
<br>
Do you think it is possible that RuntimeDyLd misses type
info data in<br>
the COFF file or doesn't wire it up correctly?<br>
I set ProcessAllSections = true, but I didn't recognize any
change. I<br>
found that RuntimeDyLdCOFF does not override finalizeLoad
like the ELF<br>
and MachO versions. The function call's comment reads "Give
the<br>
subclasses a chance to tie-up any loose ends" -- possibly
missing<br>
functionality?<br>
<br>
It would help a lot if you let me know your feeling on this
issue and/or<br>
give me a few pointers what I could check next.<br>
<br>
I can reproduce the above symptoms reliably within our
project on<br>
different Windows systems. I think I can also prepare a
self-contained<br>
repro, if you happen to have a Windows machine/VM at hand
and you are<br>
interested in clearing up this issue.<br>
<br>
Thanks.<br>
Stefan<br>
</blockquote>
</div>
</div>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="https://about.me/stefan.graenitz">https://about.me/stefan.graenitz</a></pre>
</body>
</html>