<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Lang, hi dev-list (as it may be interesting for others too)<br>
<br>
With the cpp file attached, the repro is actually as simple as this:<br>
$ clang -std=c++11 -emit-llvm repro_input.cpp -c -o repro_input.bc<br>
$ lli repro_input.bc<br>
<br>
On Mac this prints:<br>
dynamic_cast worked! dummy is 1<br>
<br>
On Windows this prints:<br>
dynamic_cast failed<br>
<br>
As the issue is reproducible with lli, it's probably unrelated to
the COFF implementation as originally stated.<br>
I built LLVM and Clang from release39 HEAD and used both, clang and
lli from this build. OS versions and CMake flags are:<br>
<br>
* OSX 10.10.6 with -DLLVM_ENABLE_RTTI=ON -DLLVM_ENABLE_EH=ON
-DLLVM_TARGETS_TO_BUILD=X86<br>
* Windows 10 64bit OS Build 14393.222 with -DLLVM_ENABLE_RTTI=ON
-DLLVM_ENABLE_EH=ON -DLLVM_TARGETS_TO_BUILD=X86
-DLLVM_USE_CRT_DEBUG=MDd -DLLVM_USE_CRT_RELEASE=MD<br>
<br>
Hope this helps nailing down the issue. Maybe I can help fixing it,
if you can provide a few pointers where to start :) If you need any
more info please let me know.<br>
<br>
Cheers<br>
Stefan<br>
<br>
<div class="moz-cite-prefix">Am 19.10.16 um 12:10 schrieb Stefan
Gränitz:<br>
</div>
<blockquote
cite="mid:6f994ad3-ef89-11a8-5fcd-49577995efe7@gmail.com"
type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
Hi Lang, thanks for getting back to this.<br>
<br>
<blockquote type="cite">Did you get a chance to run this on a
debug build? Did it trigger an assertions/unreachables? Or did
the cast just fail?</blockquote>
Yes, I use debug builds of Clang and LLVM (both 3.9.1). We have a
pretty special setup in the Projucer, but with "95% certainty": <br>
Clang output is correct. Loading the binary objects with
RuntimeDyLd produces the problem. I spent quite some time
debugging this and the fact that data is incomplete though it's in
the right place feels similar to what I experienced with
exceptions on Win64 (which turned out to be missing registration
calls <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://llvm.org/bugs/show_bug.cgi?id=24233">https://llvm.org/bugs/show_bug.cgi?id=24233</a>).<br>
<br>
<blockquote type="cite">Will you be at the dev meeting? We could
take a look at this in one of the labs.</blockquote>
Sooner or later I will make it to a Bay Area dev meeting, promise!
Unfortunately not in November as I will be at ADC in London.
However, I will try to reproduce the issue in a minimal example
during our Berlin Hackday on Saturday, that's a good challenge! If
successful I will put it on GitHub and let you know! Maybe you
guys then find a solution or make a plan at the dev meeting.<br>
<br>
Thanks<br>
Stefan<br>
<br>
<div class="moz-cite-prefix">Am 18.10.16 um 21:35 schrieb Lang
Hames:<br>
</div>
<blockquote
cite="mid:CALLttgqsvVeTKVWyDTD1iuDVuj+NgdPT-aU5utdw2emEMxMmqA@mail.gmail.com"
type="cite">
<div dir="ltr">Hi Stefan,
<div><br>
</div>
<div>Did you get a chance to run this on a debug build? Did it
trigger an assertions/unreachables? Or did the cast just
fail?</div>
<div><br>
</div>
<div>Will you be at the dev meeting? We could take a look at
this in one of the labs.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Lang.</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Oct 11, 2016 at 1:52 AM,
Stefan Gränitz <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:stefan.graenitz@gmail.com" target="_blank">stefan.graenitz@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div 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?<span
class=""><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>
</span> There's some more details in the original mail.<br>
<br>
Thanks<br>
Stefan<br>
<br>
<div class="m_4346827679977880434moz-cite-prefix">Am
07.10.16 um 02:29 schrieb Lang Hames via llvm-dev:<br>
</div>
<blockquote type="cite">
<div>
<div class="h5">
<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>
</div>
</div>
<pre>______________________________<wbr>_________________
LLVM Developers mailing list
<a moz-do-not-send="true" class="m_4346827679977880434moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a moz-do-not-send="true" class="m_4346827679977880434moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><span class="HOEnZb"><font color="#888888">
</font></span></pre><span class="HOEnZb"><font color="#888888">
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<pre class="m_4346827679977880434moz-signature" cols="72">--
<a moz-do-not-send="true" class="m_4346827679977880434moz-txt-link-freetext" href="https://about.me/stefan.graenitz" target="_blank">https://about.me/stefan.<wbr>graenitz</a></pre>
</font></span></div>
</blockquote></div>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://about.me/stefan.graenitz">https://about.me/stefan.graenitz</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>