similar to: [LLVMdev] Exception handling: How to use SJLJ EH with invoke

Hi, >> from the exist llvm-ir it seems there are some common info for sjlj-eh >> and dwarf-eh! >> are there possible use the exist llvm-ir to generate exception table > >for sjlj-eh ? >No. There should be support from llvm-gcc. sjlj eh and dwarf eh have >different semantics different semantics ? ! I think llvm-gcc generate the IR should not include the exception

Hi, many people suggest that if we want llvm to support sjlj-eh, we should modify the llvm-gcc to generate sjlj-style IR. yeah, I'm digging into the llvm-gcc now. there are some functions, at the llvm-gcc e.g TreeToLLVM::CreateExceptionValues() , BasicBlock *TreeToLLVM::getPostPad(unsigned RegionNo), void TreeToLLVM::EmitLandingPads(), void TreeToLLVM::EmitPostPads() , void

Hi, >There's definitely more to it than the current intrinsics, which are >there to support dwarf. that's to say we need modify the llvm-gcc so the front end can generate the sjlj-style IR, >SJLJ exceptions rely on runtime library >functions to register and unregister call frames which require >unwinding, so we need to modify LLVM to handle generating those call my

Hi, >There's definitely more to it than the current intrinsics, which are >there to support dwarf. from the exist llvm-ir it seems there are some common info for sjlj-eh and dwarf-eh! are there possible use the exist llvm-ir to generate exception table for sjlj-eh ? zhangzw

Hi, I meet an issue when I verify machineinstrs for Powerpc testcases in llvm. llc -mtriple=powerpc64-unknown-linux-gnu < llvm/llvm/test/CodeGen/PowerPC/sj-ctr-loop.ll -verify-machineinstrs Bad machine code: MBB exits via unconditional fall-through but ends with a barrier instruction! *** function: main basic block: %bb.2 for.body.lr.ph (0x100275437e8) Content in block BB.2:

On Jul 22, 2011, at 11:52 PM, Cameron Zwarich wrote: > On Jul 22, 2011, at 11:44 PM, Jakob Stoklund Olesen wrote: > >> 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

On Feb 9, 2013, at 4:14 PM, Anthony Bryant <antjbryant at gmail.com> wrote: > Greetings, > > I'm trying to implement exception handling in my front end. I have a > prototype working using the Itanium ABI on Linux x86_64, but I'm not > sure how to proceed for other platforms. > > So I was wondering: which OS/architecture combinations support > zero-cost EH,

Hi, I want to implement an exceptions support in some compiler I'm currently working on. I've read the documentation and some articles (like http://llvm.org/docs/ExceptionHandling.html or http://blog.llvm.org/2011/11/llvm-30-exception-handling-redesign.html). I've also checked out C++ implementation for Unix-like systems. There are many things I don't understand. 1. landingpad

On 30/09/16 20:10, Reid Kleckner wrote: > On Mon, Sep 19, 2016 at 4:42 AM, Jonas Maebe <jonas-devlists at watlock.be > <mailto:jonas-devlists at watlock.be>> wrote: > > So, can I use invoke and landingpad without using any of the other > exception handling intrinsics? (in combination with a dummy personality > function) Or will LLVM in all cases insist on

Hi Duncan, thanks ! hehe . >> Why do you want the names anyway? because i 'am working on llvm to support sjlj-eh for my target. for my side, I lookup the llvm invoke instruction to build the sjlj-eh on sjlj-eh it's need store the landing pad index to stack before call __cxa_throw, but it seems no ! in llvm-backend because it only suport dwarf-eh! so i have to build

Hi Duncan, >>I don't get it. Sorry my bad English! hehe. >>What has this got to do with determining the >>names "@__cxa_throw" and "@_ZTi"? Record the Information into the MachineModule Info, so in Dwarfwriter or SjLjWriter(my sjlj-eh name) can build the except table correctly! 2009/3/26 Duncan Sands <baldrick at free.fr>: > Hi zhangzw,

On Jul 22, 2011, at 11:44 PM, Jakob Stoklund Olesen wrote: > 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

Hi zhangzw, > >> Why do you want the names anyway? > > because i 'am working on llvm to support sjlj-eh for my target. > for my side, I lookup the llvm invoke instruction to build the sjlj-eh > on sjlj-eh it's need store the landing pad index to stack before > call __cxa_throw, > but it seems no ! in llvm-backend because it only suport dwarf-eh!

Hi Bill, Thanks for the response, I just have a couple more questions. On 11 February 2013 06:45, Bill Wendling <wendling at apple.com> wrote: > As far as which OS/architectures support zero-cost EH and which > support SJLJ, LLVM is designed to assume that Intel supports zero-cost > exceptions and ARM supports SjLj exceptions. However, it's all in the > personality function

my ugly way about the sjlj-eh is: in the last part of the llvm codegen build some relative sjlj-eh runtime function. ok, why i do like that, because i want quick run of the sjlj-en for my target., above method,based on the dwarf-eh(llvm used), now the other work of my method are emit except table, also base on llvm, now i have problem about the emit except table for sjlj. because llvm used

On 6 March 2014 18:09, Mark Seaborn <mseaborn at chromium.org> wrote: > LowerAtomic "lowers atomic intrinsics to non-atomic form for use in a > known non-preemptible environment". LowerInvoke strips out exception > handling by converting invokes to calls, so that landingpads, resumes, etc. > become dead and can be removed by a later pass. > > (As an aside,

On Mon, Sep 19, 2016 at 4:42 AM, Jonas Maebe <jonas-devlists at watlock.be> wrote: > Reid Kleckner wrote: > > On Fri, Sep 16, 2016 at 10:13 AM, Jonas Maebe via llvm-dev > > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > model. In order to ensure that changes performed in a try/setjmp==0 > > block survive

Everyone, I'm running R CMD check on a package using the 2.6.0 alpha version: > sessionInfo() R version 2.6.0 alpha (2007-09-09 r42809) i386-pc-mingw32 locale: LC_COLLATE=English_United States.1252;LC_CTYPE=English_United States.1252;LC_MONETARY=English_United States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils

Greetings, I'm trying to implement exception handling in my front end. I have a prototype working using the Itanium ABI on Linux x86_64, but I'm not sure how to proceed for other platforms. So I was wondering: which OS/architecture combinations support zero-cost EH, and which support SJLJ? My main concern is keeping the IR for call sites platform independent. Right now, it looks like to

For those of you who want to get their exception handling code (NON SJLJ), working with the new 3.0 exception infrastructure, the core developers have created a handy function in AutoUpgrade (#include "llvm/AutoUpgrade.h") called: UpgradeExceptionHandling(...). This function will convert all the functions in a module using the pre 3.0 exception intrinsics into use of the new 3.0