similar to: [LLVMdev] x86 unwind support[MESSAGE NOT SCANNED]

On Mon, Jul 20, 2009 at 7:43 AM, Nick Johnson<nicholas.paul.johnson at gmail.com> wrote: > On Mon, Jul 20, 2009 at 10:09 AM, Mark Shannon<marks at dcs.gla.ac.uk> wrote: >> Andrew Haley wrote: >> If you can make your point without any references to any C/C++ specific >> features it might be more convincing ;) >> > > I did.  Recall my mention of

Nick Johnson wrote: > On Mon, Jul 20, 2009 at 10:09 AM, Mark Shannon<marks at dcs.gla.ac.uk> wrote: >> Andrew Haley wrote: >> If you can make your point without any references to any C/C++ specific >> features it might be more convincing ;) >> > > I did. Recall my mention of java/c#/ruby/python's finally/ensure The finally block is just a bit of

On Mon, Jul 20, 2009 at 10:09 AM, Mark Shannon<marks at dcs.gla.ac.uk> wrote: > Andrew Haley wrote: > If you can make your point without any references to any C/C++ specific > features it might be more convincing ;) > I did. Recall my mention of java/c#/ruby/python's finally/ensure blocks, or C#'s using blocks. For proper implementation, these need multi-level unwinds,

Andrew Haley wrote: > Mark Shannon wrote: >> Andrew Haley wrote: >>> Mark Shannon wrote: >>>> Andrew Haley wrote: >>>>> Mark Shannon wrote: >>>>>> Nick Johnson wrote: >>>>>>>> probably there should be a switch to choose whether codegen should turn >>>>>>>> unwind/invoke into dwarf or

Mark Shannon wrote: > Andrew Haley wrote: >> Mark Shannon wrote: >>> Andrew Haley wrote: >>>> Mark Shannon wrote: >>>>> Nick Johnson wrote: >>>>>>> probably there should be a switch to choose whether codegen should turn >>>>>>> unwind/invoke into dwarf or setjmp/longjmp style code. >>>>> It seems

On Mon, Jul 20, 2009 at 7:09 AM, Mark Shannon<marks at dcs.gla.ac.uk> wrote: > For languages with finalizers such as Python or Java, a special > finalizer thread can do the cleaning up lazily once the GC has collected > the dead objects. Both Java and Python support "finally" clauses, which are roughly equivalent in this context. -Eli

Andrew Haley wrote: > Mark Shannon wrote: >> Andrew Haley wrote: >>> Mark Shannon wrote: >>>> Nick Johnson wrote: >>>>>> probably there should be a switch to choose whether codegen should turn >>>>>> unwind/invoke into dwarf or setjmp/longjmp style code. >>>> It seems to me that there is an implicit, and undocumented,

Mark Shannon wrote: > Andrew Haley wrote: >> Mark Shannon wrote: >>> Nick Johnson wrote: >>>>> probably there should be a switch to choose whether codegen should turn >>>>> unwind/invoke into dwarf or setjmp/longjmp style code. >>> It seems to me that there is an implicit, and undocumented, assumption >>> that unwinding needs to

Andrew Haley wrote: > Mark Shannon wrote: >> Nick Johnson wrote: >>>> probably there should be a switch to choose whether codegen should turn >>>> unwind/invoke into dwarf or setjmp/longjmp style code. >> It seems to me that there is an implicit, and undocumented, assumption >> that unwinding needs to handle stack-allocated objects. >> >>

Andrew Haley wrote: > Mark Shannon wrote: >> Andrew Haley wrote: > >>> Let's go back a bit. Your claim is that there is no need to unwind >>> frame-by-frame, an unwind simply needs to make a single jump to an >>> invoke instruction and restore the context (which in x86 is just 6 >>> registers). (This is, more or less, what longjmp() does.)

Mark Shannon wrote: > Andrew Haley wrote: >> Let's go back a bit. Your claim is that there is no need to unwind >> frame-by-frame, an unwind simply needs to make a single jump to an >> invoke instruction and restore the context (which in x86 is just 6 >> registers). (This is, more or less, what longjmp() does.) Duncan Sands >> explained to you why that

> In languages without stack-allocated objects (ie. most languages that > support exceptions) there is no need to unwind frame-by-frame, the > unwind simply needs to make a single jump to the invoke instruction and > restore the context (which in x86 is just 6 registers). > No. Java, C#, Ruby and Python all support the finally/ensure block; C# supports the using( IDisposable x

Nick Johnson wrote: >> probably there should be a switch to choose whether codegen should turn >> unwind/invoke into dwarf or setjmp/longjmp style code. It seems to me that there is an implicit, and undocumented, assumption that unwinding needs to handle stack-allocated objects. In languages without stack-allocated objects (ie. most languages that support exceptions) there is no

Mark Shannon wrote: > Nick Johnson wrote: >>> probably there should be a switch to choose whether codegen should turn >>> unwind/invoke into dwarf or setjmp/longjmp style code. > > It seems to me that there is an implicit, and undocumented, assumption > that unwinding needs to handle stack-allocated objects. > > In languages without stack-allocated objects

Andre Tavares wrote: > Can someone tell me how to use ACATS? I have searched for documentation, > but found none. The ACATS is here: http://www.ada-auth.org/acats.html including various documentation. It stands for "Ada Conformity Assessment Test Suite". - Bob

On 01.12.2010 09:25, John McCall wrote: > > One problem I foresee is that it's possible for a dispatch block to become unreachable from its landing pad. If that block is then deleted, we'd lose information about what's supposed to unwind there. This could happen if, e.g., someone had a noreturn destructor. In languages that usefully allow throws from EH destructors (i.e. Ada)

On Dec 1, 2010, at 12:55 AM, Sebastian Redl wrote: > On 01.12.2010 09:25, John McCall wrote: >> >> One problem I foresee is that it's possible for a dispatch block to become unreachable from its landing pad. If that block is then deleted, we'd lose information about what's supposed to unwind there. This could happen if, e.g., someone had a noreturn destructor. In

On Dec 1, 2010, at 1:14 AM, John McCall wrote: > On Dec 1, 2010, at 12:55 AM, Sebastian Redl wrote: > >> On 01.12.2010 09:25, John McCall wrote: >>> >>> One problem I foresee is that it's possible for a dispatch block to become unreachable from its landing pad. If that block is then deleted, we'd lose information about what's supposed to unwind there.

This is a forward of a question from the SourceForge LLVM forum. If anyone has experience with Cygwin and building the C front-end there, please reply and CC Alex. --- Post by Alex Vinokur below --- =============== Windows 2000 GNU gcc 3.3.3 (cygwin special) =============== ./configure ./make I have got compilation error ------------------------------- make[1]: Entering directory

> probably there should be a switch to choose whether codegen should turn > unwind/invoke into dwarf or setjmp/longjmp style code. There is, but it happens before codegen and is slow. -enable-correct-eh-support will translate invoke/unwind into setjmp/longjmp pairs for the correct behavior. See: http://llvm.org/docs/Passes.html#lowerinvoke Nick > > Ciao, > > Duncan. >