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

Thu Sep 28 12:37:33 PDT 2017

> I tried loading the "msvcrt.lib" as a archive. That was... a bad idea!
> I get a Exception while loading:
> Assertion failed: ((int64_t)Result <= INT32_MAX) && "Relocation
> overflow", file
> \lib\executionengine\runtimedyld\Targets/RuntimeDyldCOFFX86_64.h, line 81
It's a limitation of the COFF/PE format and unrelated to exceptions.
This patch explains it and shows a workaround:
https://github.com/weliveindetail/pj-llvm/commit/97cd336d458ae9c73232d1b539ceefcdb2f5eb0f

> Is there no hope left?
Well at least I am not aware of a solution.

Am 28.09.17 um 16:04 schrieb bjoern.gaier at horiba.com:

> Hello Stefan,
>
> 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.
>
> 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.
>
> I tried loading the "msvcrt.lib" as a archive. That was... a bad idea!
> I get a Exception while loading:
> Assertion failed: ((int64_t)Result <= INT32_MAX) && "Relocation
> overflow", file
> \lib\executionengine\runtimedyld\Targets/RuntimeDyldCOFFX86_64.h, line 81
>
> Research didn't helped me! My code was compiled with /MD, but it
> didn't changed. So I'm still stupid D:
> 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...
>
> Is there no hope left?
>
> Kind regards
> Björn
>
>
>
> From:        Stefan Gränitz <stefan.graenitz at gmail.com>
> To:        bjoern.gaier at horiba.com, llvm-dev at lists.llvm.org
> Date:        27.09.2017 23:09
> Subject:        Re: [llvm-dev] Clang/LLVM JIT - When to use
> "registerEHFrames()"
> ------------------------------------------------------------------------
>
>
>
> 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>_
> <mailto:cfe-dev at lists.llvm.org>, "cfe-dev"
> _<cfe-dev-bounces at lists.llvm.org>_ <mailto: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_ <mailto: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_
>
>
> 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. 

-- 
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/20170928/77a0f503/attachment.html>