similar to: [LLVMdev] Requirements for the EH representation

On Apr 13, 2011, at 2:06 AM, Renato Golin wrote: > I'll read your email with greater care along the week, but I have > added a page on the wiki to help us organise our thoughts. > > http://wiki.llvm.org/Exception_Handling If you want to volunteer to keep track of the discussion on the wiki, I think that would be great. I don't think we're going to hold the discussion on

Hi John, I'll read your email with greater care along the week, but I have added a page on the wiki to help us organise our thoughts. http://wiki.llvm.org/Exception_Handling I'll change it as I go reading your email, but for now, I've separated into each of the requirements you said. New ones could be added, existing ones merged, but the most important is to add more complete

On Apr 13, 2011, at 21:43 CDT, John McCall wrote: > And it's okay to have limited goals! I personally don't; I think we > should aim to get the IR design good enough to support crazy resumptive > languages with crazy custom unwinding schemes. But I need to know what > range of problems we're willing to consider solving before I can usefully > weigh different

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

Hi Reid, I’ve been following your proposal, and I’d be interested in helping out if I can. My main interest right now is in enabling C++ exception handling in clang for native (i.e. not mingw/cygwin) Windows targets (both 32-bit and 64-bit), but if I understand things correctly that will be closely related to your SEH work under the hood. I’m still trying to get up to speed on what is and is

Moving this month old RFC to llvmdev. Not sure why I sent this to cfe-dev in the first place... --- Based on code review discussion from John, he thinks filter expressions should be emitted into the body of the function with the try, rather than being outlined by the frontend. Instead of having the frontend create filter functions, we would use labels in place of typeinfo. The IR would look

I don’t know much about SEH and haven’t had time to really dig into this, but the idea of outlining functions that need to know about the frame layout sounds a bit scary. Is it really necessary? I’m wondering if you can treat the cleanups and filter functions as portions of the same function, instead of outlining them to separate functions. Can you arrange to set up the base pointer on entry to

On Sat, May 16, 2015 at 7:29 AM, Steve Cheng <steve.ckp at gmail.com> wrote: > On 2015-05-15 18:37:58 -0400, Reid Kleckner said: > > After a long tale of sorrow and woe, my colleagues and I stand here >> before you defeated. The Itanium EH representation is not amenable to >> implementing MSVC-compatible exceptions. We need a new representation that >> preserves

On Sat, Aug 15, 2020 at 8:39 PM Martin Storsjö <martin at martin.st> wrote: > Hi, > > > On Sat, 15 Aug 2020, Ivan Serdyuk wrote: > > > Just as Shoaib said, libunwind only is useful in environments > > that use > > the Itanium C++ ABI - there's really no use for it in an MSVC > > context > > (either using MSVC or

Hi, During last 2-3 days I started to get some new regressions from the libc++ testsuite, one of them is std/containers/sequences/list/list.modifiers/insert_iter_iter_iter.pass.cpp . When run under gdb this seems to be a crash under libunwind code: Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x00007ffff73d00ce in

We already have something like what you describe in the form of mingw support. It runs on Windows and handles exceptions using a DWARF-style personality function and (I think) an LLVM-provided implementation of the libc++abi library. What this doesn't do is provide interoperability with MSVC-compiled objects. For instance, you can't throw an exception from MSVC-compiled code and catch

--- wednesday 11-may-11, John McCall <rjmccall at apple.com> wrote: > > > > However, it has always seemed to me that exception > handling (at least on c++) is just a particular syntax of a > subset of coroutine semantics: > > This is certainly one way of implementing exceptions.  > Unfortunately, it would be prohibitively expensive to create > a new coroutine

On Jul 27, 2011, at 10:27 AM, Peter Lawrence wrote: > 3.b) I have been thinking about other possible control-flow-graph invariants of the > landingpad blocks and the catch blocks that they lead to, but so far have not come up > with very muchl, I wonder if anyone else is thinking about this...?... > > for example cleanups come before __cxa_begin_catch, but it isn't clear what

> 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

Hi Bill, there is clearly a misunderstanding: either I am missing something essential or you are. To clear this up, I suggest you send me evil examples and I will show you how my scheme handles them (or doesn't handle them, if I am indeed failing to see something). > This is the code that G++ generates from the example in my proposal: ... > If the call to __Z3foov throws, we need to

I don’t really have a good enough feeling for the landingpad syntax yet to comment on the most natural way to extend it yet, but creating a synthetic cleanup function to call from the personality function is what I was thinking. With the current (trunk +/- a couple of weeks) clang, compiling for an “x86_64-pc-windows-msvc” target, I’m seeing a landingpad that looks like this: lpad:

On 30 January 2015 at 20:43, Jonathan Roelofs <jonathan at codesourcery.com> wrote: > I think this dependence should be satisfied by the target system's unwinder, > whatever that is. If folks want to use this libunwind for their platform, > that's fine... but we should probably continue to use libgcc_s and libgcc_eh > on linux when that's the platform's unwinder.

On Fri, Jan 30, 2015 at 1:03 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 30 January 2015 at 20:43, Jonathan Roelofs <jonathan at codesourcery.com> > wrote: > > I think this dependence should be satisfied by the target system's > unwinder, > > whatever that is. If folks want to use this libunwind for their platform, > > that's fine...

Hi all, I'm debugging a crash in the guts of libunwind that started occuring when I changed the ASan runtime to use _Unwind_Backtrace() on OSX to report errors. The crash happens for every test case that has an ASan report in it, so I'm suspecting something's wrong with the unwind info generated by the Xcode Clang, which I'm using to build my Clang and the ASan runtime library

This example is pretty compelling, but I still think I want to limit the scope of this change to not include this feature. It's probably reasonable to hold onto the idea as future work, though. In the meantime, frontends can decide for themselves whether they want code size or stronger optimization of cleanups by doing early outlining or not. The only way we can hit the quadratic growth from