<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi, I checked last year's mails. Back then Timur and me faced the
same issue Björn reports (nulled memory in _ThrowInfo).<br>
<br>
<blockquote type="cite">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Back
then I tried to solve a related issue: SEH exceptions thrown
from code loaded with RuntimeDyld had to be caught in statically
compiled code. It turned out Windows explicitly prohibits this.
I got in touch with Microsoft people and IIRC it's due to
security concerns.</blockquote>
<div><br>
</div>
<div>Stefan -- That's an interesting restriction. :/</div>
<div>Does it prohibit exceptions thrown in JIT'd code from being
caught also in JIT'd code, or does it only apply if an exception
crosses the boundary back into statically compiled code?<br>
Do you know how they were enforcing that?</div>
</blockquote>
Igor Minin explained this was due to Data Execution Prevention (DEP)
and gave pointers to the involved functions in the OS runtime:<br>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/pipermail/llvm-dev/2016-June/100901.html">http://lists.llvm.org/pipermail/llvm-dev/2016-June/100901.html</a><br>
<br>
The whole thing gets hairy quickly. It seems like a combination of
multiple problems. So let's first collect evidence and clarify the
goal.<br>
<br>
Joseph Tremoulet from Microsoft partially confirmed Igor's
statements:<br>
<span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">"I
checked with some experts here, and they agree with your/Igor’s
assessment that
</span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">it’s
not possible to have a dynamically generated handler on x86"</span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"></span></span><br>
</span></span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">"the
llilc code only handles x86_64, not 32-bit x86; I
know the implementations of WinEH are quite
different between the two"<br>
</span></span></span></span></span></span></span>First
conclusion: No solution for JITed catch handlers on x86.</span></span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><br>
<span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><br>
</span></span></span></span></span></span></span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">I
think for most of us x86 has little prio anyway, so let's focus
on x86_64</span></span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"></span></span></span>.<br>
In theory both, JITed and static catch handlers, may be possible
here.<br>
<br>
<span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">I
disabled DEP globally on my machine and set </span></span></span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">MEM_EXECUTE_OPTION_ENABLE
explicitly:<br>
<a class="moz-txt-link-freetext" href="http://www.thewindowsclub.com/disable-data-execution-prevention">http://www.thewindowsclub.com/disable-data-execution-prevention</a><br>
<a class="moz-txt-link-freetext" href="https://github.com/Sh1ft0x0EF/metahook/blob/master/sys_launcher.cpp#L65">https://github.com/Sh1ft0x0EF/metahook/blob/master/sys_launcher.cpp#L65</a><br>
It didn't fix anything.<br>
Second conclusion: DEP may be one reason, but there must be
something else.<br>
<br>
</span></span></span>My next guess was an incompatibility
between Clang (we used for JITing) and MSVC (we used for static
compilation). Joseph:<br>
<span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">"One
thing that comes to mind is that presumably you’re not trying
to make your language/runtime’s exceptions masquerade as
MSVC++ exceptions, so I guess you’d want your static native
code to either have an SEH __try/__except or compile with
clang’s equivalents of MSVC’s /EHa and catch(…)"<br>
<br>
I tried all the combinations without success. I also compared
the compiled code between Clang 3.8 and MSVC, which showed no
reasonable difference.<br>
Second conclusion: No issue with code generation.</span></span></span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><br>
<br>
At that point we ran out of time we could spend on this. So we
postponed the feature, hoping for Microsoft to come up with a
solution at some point. Giving it another try today, I think
this looks promising:<br>
<a class="moz-txt-link-freetext" href="https://github.com/dotnet/llilc/blob/master/lib/Jit/EEMemoryManager.cpp#L250">https://github.com/dotnet/llilc/blob/master/lib/Jit/EEMemoryManager.cpp#L250</a><br>
<br>
Processing .pdata section entries, it creates and allocates
unwind blocks and funclets (handlers for catch & finally)
for </span></span></span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">CLR
</span></span></span>managed exceptions. It's probably not
directly applicable to</span></span></span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">
native exception handling</span></span></span>, but it
may provide useful information. Also there is much more
documentation available now:<br>
<a class="moz-txt-link-freetext" href="https://github.com/dotnet/coreclr/blob/master/Documentation/botr/clr-abi.md#exception-handling">https://github.com/dotnet/coreclr/blob/master/Documentation/botr/clr-abi.md#exception-handling</a><br>
<a class="moz-txt-link-freetext" href="https://llvm.org/docs/ExceptionHandling.html#exception-handling-using-the-windows-runtime">https://llvm.org/docs/ExceptionHandling.html#exception-handling-using-the-windows-runtime</a><br>
<br>
I could imagine </span></span></span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">setting
up minimal tests would be </span></span></span>a useful
first step to distinguish issues in a </span></span></span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">reproducible
</span></span></span>way.<br>
<br>
Best<br>
Stefan<br>
<br>
</span></span></span>
<div class="moz-cite-prefix">Am 29.09.17 um 19:43 schrieb Lang
Hames:<br>
</div>
<blockquote type="cite"
cite="mid:CALLttgrS9X5bRNutfWsqrhu0y6mopxbOnMJMp+mhofYh5A=Seg@mail.gmail.com">
<div dir="ltr">Hi Bjoern,
<div><br>
</div>
<div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I'm
trying to make exceptions run. I have an Object file with a
function, throwing a 1 and a second function which should
catch the 1. Normal JITTING under Windows showed me, that I
have an unresolved reference to the virtual table of
type_info. Some experiments later I was able to load
"msvcrt.lib" as an archive and could resolve the reference.
Nice - but than "??_Etype_info@@UEAPEAXI@Z" was missing too.
Ufff! I decided to ignore this. Because, when I try to load
every .lib and .obj provided by Visual Studio, I get an
assertion failure with "Relocation type not implemented
yet!". </blockquote>
<div><br>
</div>
<div>RuntimeDyldCOFF is missing a lot of relocation support.
We need a COFF expert to fix that and unfortunately I'm not
one.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I
decided to have a look at "_CxxThrowException". I inserted
my own function for the JIT and had a look at the
parameters. I got two of them. The first was the address of
the Exception-Object, which was correct. The second is the
address for the "_ThrowInfo". This address was valid too,
but all its members - except from attributes - are null. So
I can't throw this Exception. I tried to pass the address of
typeid(1) to it, or modificate the call. Nothing helped. </blockquote>
<div><br>
</div>
<div>I don't know windows exception handling well, but if it's
anything like DWARF EH then I'd be inclined to blame the
missing relocations/fixups -- the _ThrowInfo struct (or
whatever data-source ultimately populates it) probably isn't
being fixed up.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I
have no clue and no idea anymore. So... Do you have an
idea? </blockquote>
</div>
<div><br>
</div>
<div>I'm afraid I don't personally. We need some windows linker
/ system experts to take an interest in the JIT.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Back
then I tried to solve a related issue: SEH exceptions thrown
from code loaded with RuntimeDyld had to be caught in
statically compiled code. It turned out Windows explicitly
prohibits this. I got in touch with Microsoft people and IIRC
it's due to security concerns.</blockquote>
<div><br>
</div>
<div>Stefan -- That's an interesting restriction. :/</div>
<div>Does it prohibit exceptions thrown in JIT'd code from being
caught also in JIT'd code, or does it only apply if an
exception crosses the boundary back into statically compiled
code?</div>
<div>Do you know how they were enforcing that?</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Lang.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Sep 28, 2017 at 12:37 PM,
Stefan Gränitz via llvm-dev <span dir="ltr"><<a
href="mailto:llvm-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p><span class=""> </span></p>
<blockquote type="cite"><font face="sans-serif" size="2">I
tried loading the "msvcrt.lib" as a archive. That
was... a bad idea! I get a Exception while loading:</font>
<br>
<font face="sans-serif" size="2">Assertion failed:
((int64_t)Result <= INT32_MAX) &&
"Relocation overflow", file \lib\executionengine\<wbr>runtimedyld\Targets/<wbr>RuntimeDyldCOFFX86_64.h,
line 81</font></blockquote>
It's a limitation of the COFF/PE format and unrelated to
exceptions. This patch explains it and shows a workaround:<br>
<a class="m_8479653584311911203moz-txt-link-freetext"
href="https://github.com/weliveindetail/pj-llvm/commit/97cd336d458ae9c73232d1b539ceefcdb2f5eb0f"
target="_blank" moz-do-not-send="true">https://github.com/<wbr>weliveindetail/pj-llvm/commit/<wbr>97cd336d458ae9c73232d1b539ceef<wbr>cdb2f5eb0f</a><span
class=""><br>
<br>
<blockquote type="cite"><font face="sans-serif" size="2">Is
there no hope left?</font></blockquote>
</span> Well at least I am not aware of a solution.<br>
<br>
Am 28.09.17 um 16:04 schrieb <a
class="m_8479653584311911203moz-txt-link-abbreviated"
href="mailto:bjoern.gaier@horiba.com" target="_blank"
moz-do-not-send="true">bjoern.gaier@horiba.com</a>:<br>
<div>
<div class="h5">
<blockquote type="cite"><font face="sans-serif"
size="2">Hello Stefan,</font> <br>
<br>
<font face="sans-serif" size="2">I'm happy someone
replied to my problem! Many thanks! To be
honest... I didn't understood much of your mail.
I'm a beginner with the JIT - so I will explain
what I've done.</font> <br>
<br>
<font face="sans-serif" size="2">To manage the
memory and resolve symbols, I'm using my own
Resolver-Class, which overloads the allocation and
the findSymbol functions. I've noticed today, that
the "registerEHFrames" function of my class gets
called automatically, with correct values. I'm
remapping my code and the address are still
correct. Great! But, what should I do with it? I
pass the values to the original function, but my
exception won't be caught! It's an exception
raised inside the JITTED code and should also
catched there.</font> <br>
<br>
<font face="sans-serif" size="2">I tried loading the
"msvcrt.lib" as a archive. That was... a bad idea!
I get a Exception while loading:</font> <br>
<font face="sans-serif" size="2">Assertion failed:
((int64_t)Result <= INT32_MAX) &&
"Relocation overflow", file \lib\executionengine\<wbr>runtimedyld\Targets/<wbr>RuntimeDyldCOFFX86_64.h,
line 81</font> <br>
<br>
<font face="sans-serif" size="2">Research didn't
helped me! My code was compiled with /MD, but it
didn't changed. So I'm still stupid D:</font> <br>
<font face="sans-serif" size="2">The JITTED code
must be loaded to shared memory later - there
aren't libraries, so even if this would work, it
wouldn't help me. I tried compiling my code with
sjlj-exceptions. Didn't worked...</font> <br>
<br>
<font face="sans-serif" size="2">Is there no hope
left?</font> <br>
<br>
<font face="sans-serif" size="2">Kind regards</font>
<br>
<font face="sans-serif" size="2">Björn</font> <br>
<br>
<br>
<br>
<font face="sans-serif" size="1" color="#5f5f5f">From:
</font><font face="sans-serif" size="1">Stefan
Gränitz <a
class="m_8479653584311911203moz-txt-link-rfc2396E"
href="mailto:stefan.graenitz@gmail.com"
target="_blank" moz-do-not-send="true"><stefan.graenitz@gmail.com></a></font>
<br>
<font face="sans-serif" size="1" color="#5f5f5f">To:
</font><font face="sans-serif" size="1"><a
class="m_8479653584311911203moz-txt-link-abbreviated"
href="mailto:bjoern.gaier@horiba.com"
target="_blank" moz-do-not-send="true">bjoern.gaier@horiba.com</a>,
<a
class="m_8479653584311911203moz-txt-link-abbreviated"
href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a></font>
<br>
<font face="sans-serif" size="1" color="#5f5f5f">Date:
</font><font face="sans-serif" size="1">27.09.2017
23:09</font> <br>
<font face="sans-serif" size="1" color="#5f5f5f">Subject:
</font><font face="sans-serif" size="1">Re:
[llvm-dev] Clang/LLVM JIT - When to use
"registerEHFrames()"</font> <br>
<hr noshade="noshade"> <br>
<br>
<br>
<font size="3">Hi Björn<br>
<br>
To first answer your questionin the subject: For
x86 registerEHFrames() is only a stub. For x86_64
registerEHFrames() is implemented properly in
RuntimeDyldCOFFX86_64, calling
MemMgr.registerEHFrames() for each EH frame
section. It should be called and work out of the
box without your involvement, but unfortunately it
won't solve your issue. All the essential
information is there in the comments, just check
the base classes.<br>
<br>
This thread from last year helps with your
unresolved symbol:</font><font size="3"
color="blue"><u><br>
</u></font><a
href="http://lists.llvm.org/pipermail/llvm-dev/2016-October/106458.html"
target="_blank" moz-do-not-send="true"><font
size="3" color="blue"><u>http://lists.llvm.org/<wbr>pipermail/llvm-dev/2016-<wbr>October/106458.html</u></font></a><font
size="3"><br>
<br>
Back then I tried to solve a related issue: SEH
exceptions thrown from code loaded with
RuntimeDyld had to be caught in statically
compiled code. It turned out Windows explicitly
prohibits this. I got in touch with Microsoft
people and IIRC it's due to security concerns.<br>
<br>
Depending on your specific case, you may want to
fall back to </font><font face="Calibri" size="2">vectored
exception handling. In my experience this was a
dead end though. If you need a solution for
arbitrary situations, you just can't jump back to
a "safe" place to continue execution. I tried
setjump (on each entry point to the dynamically
loaded code) / longjmp (in the vectored exception
handler), but the address was invalidated when I
accessed it. I suspect it's kind of undefined
behavior to call longjmp outside a child frame of
the function that called setjmp. Anyway it turned
all far too hacky.</font><font size="3"><br>
<br>
If you are willing to do research, compare
implementations and behavior with the MachO and
ELF versions. At least one of them works, just not
on Windows ;)<br>
Also check the LLILC project: </font><a
href="https://github.com/dotnet/llilc"
target="_blank" moz-do-not-send="true"><font
size="3" color="blue"><u>https://github.com/dotnet/<wbr>llilc</u></font></a><font
size="3"> I heard about some solution that uses
trampolines to push exceptions back to dynamically
loaded code and handle them there.<br>
<br>
AND disclaimer: I did not follow recent
developments in this area. If there's news please
let me know!<br>
<br>
Cheers & Good Luck!<br>
Stefan</font>
<p><font size="3">Am 25.09.17 um 11:31 schrieb via
llvm-dev:</font> <br>
<font face="sans-serif" size="2">Hello friendly
LLVM-World,</font><font size="3"> <br>
</font><font face="sans-serif" size="2"><br>
because I don't know if I had send my problem to
the correct Mailing-List, I will send my problem
to this address too. I'm not subscribed to this
list, so please add my in CC if you response.</font><font
size="3"> <br>
</font><font face="sans-serif" size="2"><br>
Kind regards</font><font size="3"> </font><font
face="sans-serif" size="2"><br>
Björn</font><font size="3"> <br>
<br>
</font><font face="sans-serif" size="1"
color="#5f5f5f"><br>
From: </font><font face="sans-serif"
size="1">Bjoern Gaier/HE/HORIBA</font><font
size="3"> </font><font face="sans-serif"
size="1" color="#5f5f5f"><br>
To: </font><font face="sans-serif"
size="1">Clang Dev </font><a
href="mailto:cfe-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true"><font
face="sans-serif" size="1" color="blue"><u><cfe-dev@lists.llvm.org></u></font></a><font
face="sans-serif" size="1">, "cfe-dev" </font><a
href="mailto:cfe-dev-bounces@lists.llvm.org"
target="_blank" moz-do-not-send="true"><font
face="sans-serif" size="1" color="blue"><u><cfe-dev-bounces@lists.llvm.<wbr>org></u></font></a><font
size="3"> </font><font face="sans-serif"
size="1" color="#5f5f5f"><br>
Date: </font><font face="sans-serif"
size="1">19.09.2017 08:05</font><font size="3">
</font><font face="sans-serif" size="1"
color="#5f5f5f"><br>
Subject: </font><font face="sans-serif"
size="1">Clang/LLVM JIT - When to use
"registerEHFrames()"</font><font size="3"> <br>
</font> </p>
<hr noshade="noshade"><font size="3"><br>
</font><font face="sans-serif" size="2"><br>
Hello friendly Clang-World,</font><font size="3">
<br>
</font><font face="sans-serif" size="2"><br>
I was experimenting with Clang and the JIT
capabilities of LLVM. Most of my attempts were
successfully but, I still fail miserably at
exceptions. Doing research I found the function
"registerEHFrames()" which should assist me
supporting exceptions - but sadly the
documentation I found wasn't helpful.</font><font
size="3"> </font><font face="sans-serif" size="2"><br>
I looked at into the "notifyObjectLoaded" function
and discovered that there appear some symbol names
starting with "$" - I expected them to be
connected to my try and catch block. But what now?
As usually, at this point I have there names, but
can't get there address to register them with the
"registerEHFrames()" function. Also the JITTER
still wants an address for "??_7type_info@@6B@"
which is the virtual table of the type_info
struct.</font><font size="3"> <br>
</font><font face="sans-serif" size="2"><br>
Confusing! So friendly Clang-World, could you
please help? </font><font size="3"><br>
</font><font face="sans-serif" size="2"><br>
Not so important - but has the dragon which
decorates clang and LLVM a name?</font><font
size="3"> <br>
</font><font face="sans-serif" size="2"><br>
Kind regards</font><font size="3"> </font><font
face="sans-serif" size="2"><br>
Björn</font><font size="3"> </font><font
face="sans-serif" size="2"><br>
<br>
Als GmbH eingetragen im Handelsregister Bad
Homburg v.d.H. HRB 9816, USt.ID-Nr. DE 114 165 789<br>
Geschäftsführer: Hiroshi Kawamura, Dr Hiroshi
Nakamura, Markus Bode, Heiko Lampert, Takashi
Nagano, Takeshi Fukushima.</font><font size="3"> <br>
</font> <br>
<tt><font size="3">______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
</font></tt><a
href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true"><tt><font
size="3" color="blue"><u>llvm-dev@lists.llvm.org</u></font></tt></a><tt><font
size="3"><br>
</font></tt><a
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
target="_blank" moz-do-not-send="true"><tt><font
size="3" color="blue"><u>http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</u></font></tt></a><tt><font
size="3"><br>
</font></tt> <br>
<tt><font size="3">-- <br>
</font></tt><a
href="https://weliveindetail.github.io/blog/"
target="_blank" moz-do-not-send="true"><tt><font
size="3" color="blue"><u>https://weliveindetail.github.<wbr>io/blog/</u></font></tt></a><tt><font
size="3"><br>
</font></tt><a
href="https://cryptup.org/pub/stefan.graenitz@gmail.com"
target="_blank" moz-do-not-send="true"><tt><font
size="3" color="blue"><u>https://cryptup.org/pub/<wbr>stefan.graenitz@gmail.com</u></font></tt></a>
<br>
<br>
<font face="sans-serif" size="2"><br>
Als GmbH eingetragen im Handelsregister Bad
Homburg v.d.H. HRB 9816, USt.ID-Nr. DE 114 165 789<br>
Geschäftsführer: Hiroshi Kawamura, Dr Hiroshi
Nakamura, Markus Bode, Heiko Lampert, Takashi
Nagano, Takeshi Fukushima.</font> </blockquote>
<br>
<pre class="m_8479653584311911203moz-signature" cols="72">--
<a class="m_8479653584311911203moz-txt-link-freetext" href="https://weliveindetail.github.io/blog/" target="_blank" moz-do-not-send="true">https://weliveindetail.github.<wbr>io/blog/</a>
<a class="m_8479653584311911203moz-txt-link-freetext" href="https://cryptup.org/pub/stefan.graenitz@gmail.com" target="_blank" moz-do-not-send="true">https://cryptup.org/pub/<wbr>stefan.graenitz@gmail.com</a></pre>
</div>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
<a
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="https://weliveindetail.github.io/blog/">https://weliveindetail.github.io/blog/</a>
<a class="moz-txt-link-freetext" href="https://cryptup.org/pub/stefan.graenitz@gmail.com">https://cryptup.org/pub/stefan.graenitz@gmail.com</a></pre>
</body>
</html>