via llvm-dev
2017-Sep-25 09:31 UTC
[llvm-dev] Clang/LLVM JIT - When to use "registerEHFrames()"
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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170925/f94fdcff/attachment.html>
Stefan Gränitz via llvm-dev
2017-Sep-27 21:08 UTC
[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 at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170927/0ff676ae/attachment.html>
via llvm-dev
2017-Sep-28 14:04 UTC
[llvm-dev] Clang/LLVM JIT - When to use "registerEHFrames()"
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 at 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>