similar to: [LLVMdev] trouble understanding value in dwarf exception mechanism

Hi, On 25/04/13 07:38, edA-qa mort-ora-y wrote: > I'm having trouble understanding the value in the way exceptions are > handled on Linux, the dwarf/system V ABI exception spec. The mechanism > allows for both cleanup routines and catch handlers, where by cleanup > handlers don't stop the search for a normal handler. The personality > function (I guess no longer part of the

On 31/03/13 19:28, Duncan Sands wrote: >> How would I go about getting a custom data format stored at the >> exception landing pads (the location _Unwind_GetLanguageSpecificData >> returns)? The Dwarf encoded format is not well suited for the type of >> exception handling I wish to do in my language. > I didn't understand the question, can you please be more explicit

How would I go about getting a custom data format stored at the exception landing pads (the location _Unwind_GetLanguageSpecificData returns)? The Dwarf encoded format is not well suited for the type of exception handling I wish to do in my language. Will this be possible, or is exception handling mechanism so tightly tied to the Dwarf format that it would be extremely difficult? -- edA-qa

Hi edA-qa mort-ora-y, On 31/03/13 16:28, edA-qa mort-ora-y wrote: > How would I go about getting a custom data format stored at the > exception landing pads (the location _Unwind_GetLanguageSpecificData > returns)? The Dwarf encoded format is not well suited for the type of > exception handling I wish to do in my language. > > Will this be possible, or is exception handling

I'm working on exception handling and having some trouble with type information. My personality/types work fine when running in the JIT, but when I produce object files and link them it fails. In particular, from an action record and the LSDA I get a type table entry. The problem is this doesn't appear to be pointing to a valid location. If I derefence it a segfault occurs. Are there

I've having a bit of a problem generating output that doesn't result in the "Instruction does not dominate all uses!". In my code it relates to exception handling and how I generate the blocks. I understand exactly why I get the message, but I'm unsure of how I can structure things to avoid the problem. In a rough pseudo-code, my blocks look like this: entry: store 0,

I am having some trouble getting my catch clauses to appear as expected in the dwarf exception tables. I have an instruction like this: %0 = landingpad i64 personality i32 (i32, i32, i64, i8*, i8*)* @leaf_exception_personality catch i8* inttoptr (i64 987 to i8*) catch i8* inttoptr (i64 2453 to i8*) In my exception handler I walk through the records. I always get the correct

I'm trying to add some basic exception handling to my language now and I'm uncertain of how I actually start the exception propagation. It appears that "resume" will continue the exception, but I see no mention of how the exception actually starts. If I look at the IR output of a simple C++ program I see that it calls @__cxa_throw, but that is a library function. Somehow I must

On 03/11/13 12:16, Henrique Santos wrote: > You could try placing a phi node at "defer_block" with incoming value > "result" > when the incoming block is "entry", and do the same for "null" and > "landing". > Then, instead of loading "result", you load the value given by the newly > created phi. That seems like the

On Mon, May 18, 2015 at 11:48 AM, Steve Cheng <steve.ckp at gmail.com> wrote: > On 2015-05-18 13:32:54 -0400, Reid Kleckner said: > >> >> Right, doing our own personality function is possible, but still has half >> the challenge of using __CxxFrameHandler3, and introduces a new runtime >> dependency that isn't there currently. Given that it won't save

On 17/10/13 23:57, Bill Wendling wrote: > There shouldn't be any special linker flags you need to use. If > you're getting segfaults, it's probably trying to access the data at > an invalid location or something. Make sure that your EH table is > properly aligned. You might want to hand calculate the values to make > sure that they're correct. What platform are you

I am working on adding support for C++ exception handling when compiling for a native Windows target (that is a target with "MSVC" specified as the environment). Because of differences between how the native Windows runtime handles exceptions and the Itanium-based model used by current LLVM exception handling code, I believe this will require some extensions to the LLVM IR, though

In the past people in #llvm suggested to me I should use landing pads instead of seh when it comes to Windows unless i really need seh. Looking at what gets generated win64 -gnu does use seh but calls the landing pad somehow, while win32 doesn't at all. It looks to me a custom win64 landing pad personality can also deal with things like Access Violation. Is there a way to make win32 also

I have some exception handling which works fine using the JIT. Now I am producing object files and linking them, but the exception handling tables seem to be missing. I call _Unwind_RaiseException and get _URC_END_OF_STACK as a result. I produce my object file using TargetMachine::addPassesToEmitFile and then I link my resulting files with: gcc -o prog input.o -fexceptions I'm sure I'm

What? Yet another EH proposal?! This one is different from the others in that I'm planning to start implementing this shortly. But I want your feedback! I've all ready gotten a lot of feedback from Chris, John, Jim, Eric, and many others. Now is your turn! Please read this proposal and send me your comments, suggestions, and concerns. -bw

Looks sane. Thanks. Evan On Feb 1, 2008, at 1:24 AM, Nicolas Geoffray wrote: > Dear all, > > Here's a new patch with Evan's comments (thx Evan!) and some cleanups. > Now the (duplicated) exception handling code is in a new file: > lib/ExecutionEngine/JIT/JITDwarfEmitter. > > This patch should work on linux/x86 and linux/ppc (tested). > > Nicolas > Index:

Hi Reid, Thanks for the input. You wrote: > The @_Z4testv.unwind.1 helper just calls ~Inner(), but not ~Outer. That’s actually intentional. The thing to keep in mind is that all of the landing pads are going to be effectively removed by the time the final object image is generated. They are just there to facilitate the table generation, and in the __CxxFrameHandler3 case they don’t mean

Thx again Evan for the review. Here's a new patch for the JIT in itself. The major changes are: 1) A JITMemoryManager now has a flag saying "I require to know the size of what you want to emit" 2) DwarfJITEmitter is augmented with GetSize* functions 3) JITEmitter::startFunction checks if the JITMemoryManager requires to know the size. If so, it computes it and gives it through the

On Jul 22, 2011, at 10:29 PM, Bill Wendling wrote: > // Restrictions: > > There are several new invariants which will be enforced by the verifier: > > 1. A landing pad block is a basic block which is the unwind destination of an > invoke instruction. > 2. A landing pad block must have a landingpad instruction as its first non-PHI > instruction. > 3. The landingpad

This is a revision of the second exception handling proposal I sent out. You can see it here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-November/036484.html After much discussion, there are some changes to the proposal – some significant and some minor. One major point, this proposal does not address the issue of catching an exception thrown from a non-invoke instruction. However if done