[llvm-dev] Clang/LLVM JIT - When to use "registerEHFrames()"

Wed Sep 27 14:08:52 PDT 2017

Hi Björn

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.

This thread from last year helps with your unresolved symbol:
http://lists.llvm.org/pipermail/llvm-dev/2016-October/106458.html

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.

Depending on your specific case, you may want to fall back to 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.

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 ;)
Also check the LLILC project: https://github.com/dotnet/llilc I heard
about some solution that uses trampolines to push exceptions back to
dynamically loaded code and handle them there.

AND disclaimer: I did not follow recent developments in this area. If
there's news please let me know!

Cheers & Good Luck!
Stefan

Am 25.09.17 um 11:31 schrieb via llvm-dev:
> Hello friendly LLVM-World,
>
> 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.
>
> Kind regards
> Björn
>
>
> From:        Bjoern Gaier/HE/HORIBA
> To:        Clang Dev <cfe-dev at lists.llvm.org>, "cfe-dev"
> <cfe-dev-bounces at lists.llvm.org>
> Date:        19.09.2017 08:05
> Subject:        Clang/LLVM JIT - When to use "registerEHFrames()"
> ------------------------------------------------------------------------
>
>
> Hello friendly Clang-World,
>
> 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.
> 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.
>
> Confusing! So friendly Clang-World, could you please help?
>
> Not so important - but has the dragon which decorates clang and LLVM a
> name?
>
> Kind regards
> Björn
>
> Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816,
> USt.ID-Nr. DE 114 165 789
> Geschäftsführer: Hiroshi Kawamura, Dr Hiroshi Nakamura, Markus Bode,
> Heiko Lampert, Takashi Nagano, Takeshi Fukushima.
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
https://weliveindetail.github.io/blog/
https://cryptup.org/pub/stefan.graenitz@gmail.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170927/0ff676ae/attachment.html>