similar to: [LLVMdev] Whither exceptions

Hi Dale, > Chris would like to turn on -enable-eh rather than -enable-correct-eh- > support in the llvm testsuite for those targets that support it.  The   > following patch is intended to turn it on for x86 and ppc.  Anton,   > Duncan, are you OK with this? yes, though see below. > Chris would also like to discuss renaming the EH command line   > options, and I have to agree

On Dec 20, 2007, at 9:47 AM, Chris Lattner wrote: > On Thu, 20 Dec 2007, Duncan Sands wrote: >> Hi Dale, >>> If these were visible to end users I would not like exposing sjlj, >>> an >>> implementation detail; however my understanding is that they >>> aren't. On the basis that they're intended for use by llvm >>> geeks, I think

On Thu, 20 Dec 2007, Duncan Sands wrote: > Hi Dale, >> If these were visible to end users I would not like exposing sjlj, an   >> implementation detail; however my understanding is that they aren't.   >> On the basis that they're intended for use by llvm geeks, I think   >> either of these is an improvement, except in the second case I think   >> the

Chris would like to turn on -enable-eh rather than -enable-correct-eh- support in the llvm testsuite for those targets that support it. The following patch is intended to turn it on for x86 and ppc. Anton, Duncan, are you OK with this? -------------- next part -------------- A non-text attachment was scrubbed... Name: mf.patch Type: application/octet-stream Size: 669 bytes Desc: not

On Dec 20, 2007, at 9:57 AM, Chris Lattner wrote: > On Thu, 20 Dec 2007, Dale Johannesen wrote: >> I'm strongly of the opinion that you shouldn't have to say anything >> to >> get EH on targets where it works. >> -fexceptions is set up like that. > > I'm not sure I get what you mean. gcc defaults to no EH data, you > need > -fexceptions to

On Thu, 20 Dec 2007, Dale Johannesen wrote: > I'm strongly of the opinion that you shouldn't have to say anything to > get EH on targets where it works. > -fexceptions is set up like that. I'm not sure I get what you mean. gcc defaults to no EH data, you need -fexceptions to turn it on. g++ defaults it to on, because it knows the front-end. You think we should have llc

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

Hello, Bill > It may be my lack of understanding, but it appears that having -- > enable-eh set during compilation of llvm-gcc is causing extra files > to be compiled. Oh, no. They are always compiled. > They do. However, it doesn't seem to stop it from failing during > compilation of unwind-dw2.c for libgcc -- it has > "__builtin_eh_return" in it. During

Hello, Renato > Anyone has any idea on the status of exception handling in clang/LLVM? > DwarfException cannot be easily overwritten, and adding target specific > code to it seems wrong... Neither llvm-gcc nor clang support exceptions on ARM (except, maybe, sjlj excheptions on arm/darwin). I have some patched uncommitted for EH on ARM but they are too far from being complete. -- With

Hello, Samuel > While we have been discussing this, my partner discovered the source of where the sj/lj stuff is coming from.  Does this mean that the LLVM libraries we're using are broken? > > Type.cpp > ..\..\..\..\llvm\lib/libLLVMCore.a(Type.cpp.obj):Type.cpp.text+0x722): undefined reference to `__gxx_personality_sj0' >

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

I strongly advise you not to use SjLj exception handling. Use zero-cost-exceptions via DWARF instead. If you really want to pursue sjlj anyway, look at the ARM backend. It uses them for darwin targets. -Jim On Jul 12, 2013, at 9:09 AM, Nicolas Ojeda Bar <N.Ojeda.Bar at dpmms.cam.ac.uk> wrote: > Dear list, > > I want to add SJLJ exception handling to my frontend. Unfortunately,

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

hi, I'm doing to make llvm backend support sjlj-eh! I have try to use the llvm-IR to generate the sjlj-eh code, but I'm totally despair ! my major problem is that llvm-ir , I mean exception instrinstics are enough for codegen the sjlj-eh code? May I need to modify the llvm-gcc ? or someone can give some advice about llvm-backend 's support sjlj-eh ? best regards

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,

Hello, Jim > -enable-correct-eh-support, llc asserts on me. It appears there's been some > bitrot somewhere. Well, correct. Because many places expects exceptions to be dwarf-style. > Is it reasonable to expect that lowerinvoke is a good place to start for > doing what I'm after? I really don't think so. Since you're trying to map dwarf-based structures into sjlj

Hi Dale, > > this is the bit I don't understand. Why does it go > > into a loop? How can the unwinder possibly know that > > the original code did not have a catch-all, since we > > tell it which catches there are and we say: there is > > a catch-all! > > The unwinder works by doing a stack crawl to find a handler. Since > we're telling it

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

On 8/29/07, Anton Korobeynikov <asl at math.spbu.ru> wrote: > Hello, Bill > > > It may be my lack of understanding, but it appears that having -- > > enable-eh set during compilation of llvm-gcc is causing extra files > > to be compiled. > Oh, no. They are always compiled. > > > They do. However, it doesn't seem to stop it from failing during > >

Folks, I'm sorry for getting at this again, but this will not be the last discussion on the topic, so let's just get to business. We're about to merge the last critical patch to make EHABI compatible with other EH mechanisms in LLVM (D3079), and that has unearthed a few issues with the function attributes. Logan's blog post [1] contains a proposal to split unwinding from