Displaying 20 results from an estimated 2000 matches similar to: "[LLVMdev] Looking for advice on how to debug a problem with C++ style exception handling code that my compiler generates."
2015 Apr 09
2
[LLVMdev] Looking for advice on how to debug a problem with C++ style exception handling code that my compiler generates.
Hi Christian,
Andy's already covered the major points, but you could consider filing a
bug at http://llvm.org/bugs too, especially if you've got a small test-case
that demonstrates the issue. Exception handling hasn't been a priority in
the past, but as more people adopt LLVM's JIT APIs I suspect it will get
more attention, and bug reports will help us figure out what needs doing.
2015 Apr 12
2
[LLVMdev] Looking for advice on how to debug a problem with C++ style exception handling code that my compiler generates.
Hi Christian,
> I don’t see anything in the Itanium ABI that says I need to call the
function that throws an exception with “invoke” to get exception handling
to work!
AFAICT, it is the design of LLVM IR and its implementation. To catch the
exceptions thrown by the callee functions, we should use the invoke
instruction along with the landingpad instruction. If you are calling a
function
2015 Apr 12
2
[LLVMdev] Looking for advice on how to debug a problem with C++ style exception handling code that my compiler generates.
Hi Christian,
Thanks for your explanation. I know your situation now. I would suggest
you to check the optimization pass used by the JIT compiler, especially
IPO/PruneEH.cpp. It will try to add nounwind attribute to functions which
will result in the problem you have mentioned earlier.
Alternatively, as a workaround, try to add uwtable (function attribute) to
the functions that are generated
2015 Apr 12
2
[LLVMdev] Looking for advice on how to debug a problem with C++ style exception handling code that my compiler generates.
Logan,
I need to make a correction of the post that preceded this one!
I was wrong when I said this:
> When I load the bitcode file for this module and then dump it just before it is JITted, the “uwtable” attribute has disappeared - is this prune-eh doing its work even though it’s not listed above in the list of function pass managers?
The “uwtable” attribute does not disappear! I had
2015 Apr 12
2
[LLVMdev] Looking for advice on how to debug a problem with C++ style exception handling code that my compiler generates.
This is the only thing that I’ve found that works in terms of getting the exception to propagate out of the JITted function - change the “call” to an “invoke” and hook in the do-nothing landing-pad.
https://gist.github.com/drmeister/7a35046f666826206973
Compare line 646 of the file above to the one that I just posted.
> https://gist.github.com/drmeister/b97dec956c6ee9ffeb75
The first one
2015 Apr 12
2
[LLVMdev] Looking for advice on how to debug a problem with C++ style exception handling code that my compiler generates.
Logan,
How would I dump the object file generated by the JIT compiler pipeline?
Could you point me to an example of how something like that is done? I’m used to working with the JIT machinery in memory but not writing object files out to disk.
I’m have code to generate object files for AOT compilation - is it done the same way?
Best,
.Chris.
On Apr 12, 2015, at 2:27 PM, Logan Chien
2013 Oct 14
3
[LLVMdev] A weird, reproducable problem with MCJIT
I switched my Common Lisp compiler to use MCJIT on the weekend and ran
into a weird problem compiling one particular function.
It crashes with an EXC_BAD_ACCESS error in MCJIT::finalizeObject when
calling processFDE.
The weird part is that the function does not appear to do anything
special and I've whittled it down to
the minimum size that still causes the crash. If I remove even one
2013 Oct 14
0
[LLVMdev] A weird, reproducable problem with MCJIT
Hi Christian,
Thanks for sharing this.
Yaron Keren has been investigating some problems in the EH frame registration code recently, and I think this may be related. It at least sounds similar to the type of variations in behavior based on code size that Yaron was seeing.
-Andy
-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of
2013 Oct 14
3
[LLVMdev] A weird, reproducable problem with MCJIT
Hi,
I had similar problems with EH in ELF in
RTDyldMemoryManager::registerEHFrames() calling __register_frame().
I'm not sure these problems are related to this problem since your crash
happens in RuntimeDyldMachO::registerEHFrames() in its own processFDE
(there are two functions named processFDE(), one in
RuntimeDyldMachO.cpp and one in RTDyldMemoryManager.cpp) *before*
2017 Sep 28
0
Clang/LLVM JIT - When to use "registerEHFrames()"
> 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
2017 Sep 28
2
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
2017 Sep 29
2
Clang/LLVM JIT - When to use "registerEHFrames()"
Hi Bjoern,
I'm trying to make exceptions run. I have an Object file with a function,
> throwing a 1 and a second function which should catch the 1. Normal JITTING
> under Windows showed me, that I have an unresolved reference to the virtual
> table of type_info. Some experiments later I was able to load "msvcrt.lib"
> as an archive and could resolve the reference. Nice -
2017 Oct 03
2
Clang/LLVM JIT - When to use "registerEHFrames()"
I'm catching up on this. Does this mean LLVM x64 JITTed code is not
exception friendly or you can't catch exceptions inside LLVM JITTed
code. The first one seems to indicate that the code is not ABI
friendly or that not enough information is present to notify Windows
of unwind tables.
I'll ask the question another way: Does LLVM emit enough information
so that RtlAddFunctionTable can
2015 Jul 23
2
[LLVMdev] ORC and relocations
Yes, I’m handling all internal and external relocations manually in NotifyLoadedFtor and I already verified that I get the behavior I need if I comment out the call to resolveRelocations.
I would like to reuse ObjectLinkingLayer::addObjectSet (which eventually calls RuntimeDyld::loadObject), which has the right calls to the memory manager and also RuntimeDyld::registerEHFrames.
I understand that
2017 Oct 04
3
Clang/LLVM JIT - When to use "registerEHFrames()"
That's encouraging.
Assuming that all access to the JITted code is going to be done
through a function pointer, and all JIT code is ephemeral, why is the
object container format important? In fact, why is it even needed? I
found it somewhat odd that MCJIT generates an object file for even the
JIT case.
To answer my own question, could it be that advanced JIT's may
need/want to use things
2015 May 29
2
[LLVMdev] MCJit interface question
Hi,
I think I need to make a small change to the MCJit interface, and would like some feedback on what the most appropriate option would be.
I'm working on LLILC (a jit for the CoreCLR built on MCJit, which creates one module for each MSIL method, containing the main function and zero or more EH handler functions extracted from the MSIL method). The CoreCLR requires the jit to notify it of
2015 May 30
2
[LLVMdev] MCJit interface question
Agreed, that sounds like the best plan. I'll look into moving LLILC to ORC.
Thanks
-Joseph
From: Russell Hadley
Sent: Friday, May 29, 2015 8:13 PM
To: Lang Hames; Joseph Tremoulet
Cc: llvmdev at cs.uiuc.edu
Subject: RE: [LLVMdev] MCJit interface question
Hey Joseph,
What Lang said made me wonder. Is it the right time for us (LLILC) to move to ORC? The long term plan was to go there but
2017 Sep 25
2
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>
2015 Jul 24
0
[LLVMdev] ORC and relocations
Hi Eugene,
Sorry for the delayed reply. Custom relocations weren't something I had in
mind when I designed Orc, so they raise some interesting design questions
which I don't have good answers to yet. (E.g. The interface for the Orc
layer concept assumes that there's a RuntimeDyld instance embedded at the
bottom of the stack. That's why addModuleSet takes a MemoryManager and
2015 May 30
2
[LLVMdev] MCJit interface question
Hey Joseph,
What Lang said made me wonder. Is it the right time for us (LLILC) to move to ORC? The long term plan was to go there but this could be our forcing function.
-R
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Lang Hames
Sent: Friday, May 29, 2015 2:23 PM
To: Joseph Tremoulet
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] MCJit interface