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

via llvm-dev llvm-dev at lists.llvm.org
Thu Sep 28 07:04:35 PDT 2017


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>, "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


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170928/5856f975/attachment.html>


More information about the llvm-dev mailing list