<html>
<head>
<meta content="text/html; charset=GB2312" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Thanks,<br>
<br>
If LLVM can emit code that runs ok from the OS, I think what I'm
trying to do should be doable, if frustrating to implement. Can you
point me to the code that handles this functionality? I haven't
poked around much, but I can tell from reading the exception
handling spec that this isn't the default behavior. Unless I'm
seriously missing things, SEH requires placing exception handlers on
the stack along with the code that they handle, the fact that
everything calls into the same _except_handler3 function is simply a
matter of implementation, but the OS needs the address of the first
handler to be in fs:[0], which did not sound like the exception
handling behavior described in the documentation.<br>
<br>
The answer to your other question is yes, LLVM transforms!<br>
<br>
<div class="moz-cite-prefix">On 1/31/14, 4:41 PM,
<a class="moz-txt-link-abbreviated" href="mailto:endlessroad1991@gmail.com">endlessroad1991@gmail.com</a> wrote:<br>
</div>
<blockquote
cite="mid:CAEd+i-Jaq4J0Yu4LZsC+t_HmSDOCD57uGbcyV8_ppy3eiFffYw@mail.gmail.com"
type="cite">
<div dir="ltr">Short version: <span
style="font-family:arial,sans-serif;font-size:13px">"something
that works at all" - yes, </span><span
style="font-family:arial,sans-serif;font-size:13px"> "visual
c++ style SEH" - no.</span>
<div>
<span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">Long
version: this whole SEH mechanism breaks down to two levels,
actually: operating system level and compiler level.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">For
the operating system level, after OS catches any
software/hardware exception, it just calls RtlUnwind to walk
the stack and find the first stack frame that may handle
this exception and execute handler defined in that stack
frame, until exception is handled or we have to abort the
whole program. And when the handler is called, a pointer to
language-specific exception data is provided. On the </span><span
style="font-family:arial,sans-serif">OS level, OS doesn't
care what the handler is, and is not responsible for
providing the language-specific data to the exception
handler; it just calls the handler.</span></div>
<div><span style="font-family:arial,sans-serif">The handler and
language-specific data passed to exception handler are
decided on the compiler level. For example, for C programs,
the handler is _except_handler3 in CRT, for .NET program,
it's some function in .NET runtime.</span></div>
<div><span style="font-family:arial,sans-serif"><br>
</span></div>
<div><span style="font-family:arial,sans-serif">LLVM can emit
code that runs fine on operating system level. The handler
is provided by GCC runtime, and language-specific data is
Dwarf EH data. This way we can make Dwarf style C++
exception work (on top of operating system level SEH). But
we cannot link llvm-generated code and VC-generated code
together, because C++ exception model is different.</span><span
style="font-family:arial,sans-serif"><br>
</span></div>
<div><span style="font-family:arial,sans-serif"><br>
</span></div>
<div><span style="font-family:arial,sans-serif">For VC-style
SEH, it uses _except_handler3 in CRT as exception
handler(for every stack frame that is compiled with SEH
turned on), and use extra stack space as language-specific
data structure passed to _except_handler3. This is not
implemented in LLVM.</span></div>
<div><span style="font-family:arial,sans-serif"><br>
</span></div>
<div><font face="arial, sans-serif">Hope this explains something
for you. IMHO, writing Windows driver using an other-than-VC
compiler seems a lot of trouble.. Is there some feature of
clang that you really want and is missing in VC?</font></div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Sat, Feb 1, 2014 at 6:49 AM, Jb
Feldman <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:jb.feldman@kyrus-tech.com" target="_blank">jb.feldman@kyrus-tech.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Can you clarify what you mean by "real SEH
handling"? My company has me looking at this in the hopes
that I can make LLVM capable of building windows drivers.
If you mean "visual c++ style SEH", I'm fairly sure that
isn't necessary for my purposes, but it would be nice. If
you mean "something that works at all," then your concern
about generalizing LLVM exception handling probably means
that I will need to do some work learning about how
exception handling is currently implemented. Do you have a
link to the patch your discussing, or a revision number?
<div>
<br>
</div>
<div>Thanks,<br>
JB</div>
</div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Jan 31, 2014 at 6:41
AM, Kai Nacke <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:kai.nacke@redstar.de"
target="_blank">kai.nacke@redstar.de</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi
Jb, Hi Tong,<br>
<br>
with my patch LLVM emits unwind information for
Windows 64bit. The Dwarf EH encoding is used
language specific data. That is the same way gcc
implements SEH for Windows 64bit. (As a side note,
PR18546 now contains a patch for Clang to use my
patch on mingw64.)<br>
<br>
The rational behind this approach is that Windows
provides support for stack unwinding (RtlUnwind
etc.) but LLVM is inherently based on Dwarf EH.
This approach combine both worlds. If the
personality function is tolerant enough then it
should also be possible to mix exceptions.<br>
<br>
If you want to make exception handling MS
compatible then you can take my code as base. You
only need to emit the MS handler data instead of
the Dwarf data.<br>
<br>
However, at least as a first approach I would
recommend to implement 32bit SEH with a similar
approach. It should have some similarities to SjLj
exception handling - this really helps to
understand what needs to be done.<br>
<br>
"real SEH handling" requires a small function
which is called to decide if the exception is
handled. If yes then the handler is called. If not
then stack unwinding continues (after a possible
call of a cleanup handler). I found it difficult
(if not impossible) to create this code based on
the exception design of LLVM. IMHO, some some
generalizations are required.<br>
<br>
Regards,<br>
Kai
<div>
<div><br>
<br>
On 31.01.2014 05:29, <a
moz-do-not-send="true"
href="mailto:endlessroad1991@gmail.com"
target="_blank">endlessroad1991@gmail.com</a>
wrote:<br>
</div>
</div>
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div>
<div>
Hi Jb,<br>
<br>
It's good to see someone step up and take a
shot as this again. I<br>
dropped this because it seems to me it
wasn't a high priority task for<br>
LLVM/Clang.<br>
<br>
Implementing SEH is more of LLVM work than
Clang work.<br>
<br>
For 32-bit SEH, there are prologue/epilogue
instruction sequence to<br>
emit, setting try-level ([ebp-4]),
recovering EBP ([ebp-18h]), and all<br>
these can only happen in LLVM, not Clang. In
my opinion, we should<br>
implement these as LLVM intrinsics, like the
gcc ones: see<br>
<a moz-do-not-send="true"
href="http://llvm.org/docs/ExceptionHandling.html#exception-handling-intrinsics"
target="_blank">http://llvm.org/docs/ExceptionHandling.html#exception-handling-intrinsics</a>.<br>
Also, we should emit the tables for each
function, which is not a simple<br>
task either.<br>
<br>
For 64-bit SEH, things are simpler. There
are no more instructions to<br>
emit than no-SEH code. We have only two
tasks: emit the table for each<br>
function, and place some code right. If I
remember it correctly,<br>
__finally block code should be replicated at
2 places: one in the<br>
original function as part of the normal
execution path, and other one<br>
separately if anything in __try block goes
south.<br>
As for the table part, I've seen some
commits from Kai(as CC'ed in this<br>
email) doing it, you should ask him for
details.<br>
<br>
Thanks again.<br>
<br>
--<br>
Best Regards, Tong Shen (ÉòÍ®)<br>
<br>
<br>
</div>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu"
target="_blank">LLVMdev@cs.uiuc.edu</a>
<a moz-do-not-send="true"
href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev"
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br>
</blockquote>
<br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
Best Regards, Tong Shen (ÉòÍ®)
</div>
</blockquote>
<br>
</body>
</html>