search for: lsda

Hi Nick, > Just to throw out another perspective, I've wondered about optimizations we could do if we designed a new personality function. In particular, I'd like to eliminate the use of landing pads for destructing locals. Instead the LSDA would encode the pc liveness ranges of local objects, their location in the stack frame, and their destructor functions. Then the new personality function would iterator through the LSDA and call the appropriate destructors. The upshot is that functions will be smaller (no landing pad code) and t...

...ry.main* %gc_frame, i32 0, i32 0, i32 0 %gc_savedhead3 = load %gc_stackentry** %gc_frame.next2 store %gc_stackentry* %gc_savedhead3, %gc_stackentry** @llvm_gc_root_chain unwind } However, there isn't a personality function associated here. This conflicts with the fact that there's an LSDA associated with the function. It's not really feasible that there would be an LSDA but no personality function. Also note that the landing pad of the 'invoke' doesn't include any of the exception handling intrinsics. During the DwarfEHPrepare pass, an @llvm.eh.exception() call is ad...

Just to throw out another perspective, I've wondered about optimizations we could do if we designed a new personality function. In particular, I'd like to eliminate the use of landing pads for destructing locals. Instead the LSDA would encode the pc liveness ranges of local objects, their location in the stack frame, and their destructor functions. Then the new personality function would iterator through the LSDA and call the appropriate destructors. The upshot is that functions will be smaller (no landing pad code) and t...

On Nov 29, 2010, at 12:17 AM, Duncan Sands wrote: >> This is well-formed SSA; the alloca instruction %x is in the entry block and thus dominates both the store in %try and the load in %catch... > > this brings up the question of whether we should allow a catch handler to be > attached to the entry block. My feeling is that it should be disallowed. If > it was allowed then

> On Feb 2, 2015, at 6:04 PM, Reid Kleckner <rnk at google.com> wrote: > I actually like the unified intrinsic approach here. The backend already has to know things about the personality function. Until recently we would assume that the personality function wants an Itanium LSDA, for example, and dump that out into a target-specific section. Now on Windows we look at the personality function and try to figure out what kind of preparation and tables it wants. > > It seems reasonable then that we could continue along the lines of classifying some personalities as &quo...

...## CIE Augmentation .byte 1 ## CIE Code Alignment Factor .byte 120 ## CIE Data Alignment Factor .byte 16 ## CIE Return Address Column .byte 2 ## Augmentation Size .byte 16 ## LSDA Encoding = pcrel .byte 16 ## FDE Encoding = pcrel But the FDE has: .byte 0 ## Augmentation size The linker is expecting that since the CIE said there was an LSDA in each FDE that is pcrel encoded, that there would in fact be an LSDA in each FDE. Bu...

Hi, If I type define i32 @main() gc "shadow-stack" { entry: %0 = alloca i8* %1 = call i8* @malloc(i64 1) store i8* %1, i8** %0 call void @llvm.gcroot(i8** %0, i8* null) ret i32 0 } declare i8* @malloc(i64) declare void @llvm.gcroot(i8**, i8*) nounwind in test.ll and then do > llc test.ll > gcc test.s I get the error ld: in

Hi Bill, > However, there isn't a personality function associated here. This conflicts with the fact that there's an LSDA associated with the function. It's not really feasible that there would be an LSDA but no personality function. GCC recently added support for this, i.e. a situation in which there are only cleanups to be run: it uses the C personality function even if the language being compiled is not C. &g...

...pad them out like this: .section __DATA,__gcc_except_tab .align 2 GCC_except_table13: .byte 0x0 #< --- hun? .byte 0x0 #< --- hun? Lexception13: .byte 0xFF .byte 0x0 .byte 0xB2, 0x1 > Here are his comments: The problem is that the linker parses FDE which gives it all the LSDA starts. The __eh_frame and __gcc_except_tab sections should not need any labels, since the structure in them is self describing. But with this padding, the LSDA starts from the FDEs and the GCC_except_table* labels are now different. It looks like your goal is to keep the 32-bit pointers in the ca...

...rface 0: Operation not permitted 0.000925 Can't claim USB device [0764:0501]: could not detach kernel driver from interface 0: Operation not permitted # dmesg hub 2-0:1.0: state 7 ports 10 chg 0000 evt 0004 ohci_hcd 0000:00:02.0: GetStatus roothub.portstatus [1] = 0x00030300 PESC CSC LSDA PPS hub 2-0:1.0: port 2, status 0300, change 0003, 1.5 Mb/s usb 2-2: USB disconnect, address 87 usb 2-2: unregistering device usb 2-2: usb_disable_device nuking all URBs usb 2-2: unregistering interface 2-2:1.0 hub 2-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x300 hub 1-0:1.0: state...

Hi Bill, > It looks like your goal is to keep the 32-bit pointers in the call-site table 4-byte aligned. Here is another solution, instead of having two labels at the start of the LSDA (with pad bytes between them), have no pad bytes and instead use an unnormalized uleb128 for the call-site table length. By unnormalized, I mean one with leading zeros. For instance, instead of: this sounds like a good idea to me. Ciao, Duncan.

> On Feb 2, 2015, at 4:53 PM, Reid Kleckner <rnk at google.com> wrote: > This seems reasonable to me. Adding John explicitly… Thanks, Reid. Andy, I understand why Windows EH needs custom lowering here, and using intrinsics seems like a fine approach, but I don’t understand why you’re proposing changing the Itanium code generation pattern. There’s no reason for backends to have

On 21 March 2014 18:47, Logan Chien <tzuhsiang.chien at gmail.com> wrote: > * There's the table for ARM target: > > - no attribute => emit unwind table > - with nounwind => emit unwind table with cantunwind > - with uwtable => emit unwind table > - with uwtable+nounwind => emit unwind table WITHOUT the cantunwind > > The cantunwind record will stop the

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 perhaps some linker flags that I must use to get this working correctly? -- edA-qa mort-ora-y -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --...

...n the AST at all. I can't see anything related to unwinding control flow with -ast-dump for instance. I've been spending some time debugging a particular test program at bug 33778 <https://bugs.llvm.org/show_bug.cgi?id=33778> that fails to link because a block only referenced from an LSDA contains a call instruction to a destructor that has no generated definition. I'm hitting a wall because I'm pretty ignorant of the structure of the codebase and any guidance would be appreciated. Any general guidance or documentation to help find my way around clang would be awesome too....

...and the HP unwind interface is pretty low. The only call LLVM emits is to _Unwind_Resume, so you would have to go into llvm/lib/CodeGen/DwarfEHPrepare.cpp and teach LLVM what you want it to call in your runtime for your EH personality. Other than that, LLVM mostly emits ehframe unwind info and the LSDA, which describes the landingpad PCs and how to get there. You can either try to interoperate with that, or you'll have to change LLVM to emit your own LSDA format. At this point we support 3-ish distinct personalities, all with their own LSDA format, so there's a fair amount of prior art to...

...H personality function is called __C_specific_handler. On > x86, it is __except_handler4 (or 3), but it's similar to > __C_specific_handler and doesn't change how we should represent this in IR. > > The personality function interprets some side tables similar to the > Itanium LSDA to find the filter function pointers that must be evaluated to > decide which except handler to run at a given PC. The filter expressions > are emitted as separate function bodies that the personality function > calls. If a filter function returns '1', that indicates which except b...

>> It looks like your goal is to keep the 32-bit pointers in the call-site table 4-byte aligned. Here is another solution, instead of having two labels at the start of the LSDA (with pad bytes between them), have no pad bytes and instead use an unnormalized uleb128 for the call-site table length. By unnormalized, I mean one with leading zeros. For instance, instead of: > > this sounds like a good idea to me. Looks ok for me, but please postpone the patch until stuff...

On Apr 11, 2011, at 11:27 PM, Duncan Sands wrote: > Hi Bill, > >> However, there isn't a personality function associated here. This conflicts with the fact that there's an LSDA associated with the function. It's not really feasible that there would be an LSDA but no personality function. > > GCC recently added support for this, i.e. a situation in which there are only > cleanups to be run: it uses the C personality function even if the language > being co...

Dear list, I want to add SJLJ exception handling to my frontend. Unfortunately, there doesn't seem to be any examples in the documentation as to how to use the intrinsics @llvm.eh.sjlj.setjmp @llvm.eh.sjlj.longjmp @llvm.eh.sjlj.lsda @llvm.eh.sjlj.callsite Is there a way to force Clang to use SJLJ exception handling for C++? That way I would be able to look at its output to learn how to use them correctly. Otherwise, how should I go about finding out how to implement SJLJ exception handling in my frontend? Thanks! Nicolas