similar to: [LLVMdev] landingpad instruction documentation is vague

Hi Yuri, > I am new to the landingpad (which is relatively new too). > Documentation http://llvm.org/docs/LangRef.html#i_landingpad leaves some > questions open: > > 1. What happens when actual exception type isn't listed in catch or > filter clauses? Does it still return the corresponding structure like if > it was listed? Or behavior is undefined? if it doesn't

On 01/11/2012 02:37, Duncan Sands wrote: >> 1. What happens when actual exception type isn't listed in catch or >> filter clauses? Does it still return the corresponding structure like if >> it was listed? Or behavior is undefined? > if it doesn't match a clause then the exception continues to be unwound. > Note that you can match a catch clause without being equal

On Wed, Jan 11, 2012 at 11:37:50AM +0100, Duncan Sands wrote: > Hi Yuri, > > > I am new to the landingpad (which is relatively new too). > > Documentation http://llvm.org/docs/LangRef.html#i_landingpad leaves some > > questions open: > > > > 1. What happens when actual exception type isn't listed in catch or > > filter clauses? Does it still return

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

> This isn't an llvm-specific feature, but how exceptions work in general. Ugh, Q2 and Q3 are also not llvm-specific feature? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj

On Jul 31, 2011, at 11:06 AM, Duncan Sands wrote: >> //===-------------------------- >> // The 'landingpad' Instruction >> // >> >> The 'landingpad' instruction replaces the current 'llvm.eh.exception' and >> 'llvm.eh.selector' intrinsics. >> >> // Syntax: >> >> %res = landingpad<somety>

On Jan 11, 2012, at 3:15 AM, 陳韋任 wrote: > On Wed, Jan 11, 2012 at 11:37:50AM +0100, Duncan Sands wrote: >> Hi Yuri, >> >>> I am new to the landingpad (which is relatively new too). >>> Documentation http://llvm.org/docs/LangRef.html#i_landingpad leaves some >>> questions open: >>> >>> 1. What happens when actual exception type

Hi Bill, > Please read this proposal and send me your comments, suggestions, and concerns. this proposal looks great to me. Thanks for working on it. I have a few minor comments, see below. > //===-------------------------- > // The 'landingpad' Instruction > // > > The 'landingpad' instruction replaces the current 'llvm.eh.exception' and >

On Aug 1, 2011, at 11:13 PM, Bill Wendling wrote: >>> The 'landingpad' instruction replaces the current 'llvm.eh.exception' and >>> 'llvm.eh.selector' intrinsics. >>> >>> // Syntax: >>> >>> %res = landingpad<somety> personality<ty> <pers_fn> <clause>+ >>> >>> where

On Fri, Jul 22, 2011 at 10:29 PM, Bill Wendling <wendling at apple.com> wrote: [...] > //===-------------------------- > // The 'landingpad' Instruction > // > > The 'landingpad' instruction replaces the current 'llvm.eh.exception' and > 'llvm.eh.selector' intrinsics. > > // Syntax: > >  %res = landingpad <somety>

Hi Chris, >>> Is it intended that "cleanup ty_1, ty_2" potentially be different to >>> "cleanup ty_1 cleanup ty_2"? Perhaps this is useful for funky personality >>> functions. >>> >> Yeah. One can basically interleave the catches and filters. But having two catch or two filter clauses in a row should be semantically the same as the

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

On Aug 2, 2011, at 10:28 AM, Duncan Sands wrote: >>>> Is it intended that "cleanup ty_1, ty_2" potentially be different to >>>> "cleanup ty_1 cleanup ty_2"? Perhaps this is useful for funky personality >>>> functions. >>>> >>> Yeah. One can basically interleave the catches and filters. But having two catch or two filter

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

On Sep 25, 2011, at 1:02 AM, Duncan Sands wrote: > Hi Talin, > >> I'm looking at the docs, and while it refers to a "catch-all" clause, > > hopefully Bill will get rid of the first reference to "catch-all" since > that section is inaccurate. > I *think* this is now correct. Please check. :) > it doesn't >> describe how to construct

I'm looking at the docs, and while it refers to a "catch-all" clause, it doesn't describe how to construct one. In the old scheme, a selector value of 0 was used. What's the corresponding technique for the new scheme? Do I need to update my personality function to handle catch-alls (it wasn't needed in the previous scheme)? -- -- Talin -------------- next part

Hi Bill, Thanks for working on this. Is there a reference for the function attribute uwtable, or is it to be defined as part of this effort? Thanks in advance Garrison On Jul 23, 2011, at 1:29, Bill Wendling wrote: > 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

Hi Bill, >>> I'm looking at the docs, and while it refers to a "catch-all" clause, >> >> hopefully Bill will get rid of the first reference to "catch-all" since >> that section is inaccurate. >> > I *think* this is now correct. Please check. :) I still have some niggles: The unwinder delegates the decision of whether to stop in a

> > 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

Hi, > maybe this should not be here! does this have anything to do with LLVM? > int main() > { > try { > throw 34; > } > catch (int) { > } > catch (char) { > } > catch (bool) { > } > } The action is 0x5, this refers to 123 .byte 0x3 124 .byte 0x7d where 0x3 means that the typeinfo