similar to: Rsync over an NFS mount (Scanned @ Decoma)

Gordon Henriksen wrote: > On Jan 23, 2009, at 06:23, Mark Shannon wrote: > >>> On Jan 22, 2009, at 3:45 AM, Mark Shannon wrote: >>> >>>> I need to get the address of a label in jitted code. (This is so >>>> that I can insert a jump into the machine code to resume >>>> interpretation from compiled code) >>> What's your

On Jan 23, 2009, at 10:06 AM, Mark Shannon wrote: > Dan Gohman wrote: >> >> LLVM doesn't support taking the real address of a label. It may >> some day, but that won't by itself make it safe to jump into >> compiled code from separately-compiled code. To do that, you'd >> need to arrange some stable set of assumptions about the state >> of the

Gordon Henriksen wrote: > You'll certainly need to map roots on the stack and use write barriers. > > • shadow-stack is an easy, portable way to bring up root discovery. > You can switch to static stack maps later (with the requirement that > your runtime be able to crawl the machine stack, which is out-of-scope > for LLVM unless Talin makes some progress with his GC

Hi, Can I interject something at this point. Can I suggest that invoke/unwind be renamed DWARF_invoke/DWARF_unwind to warn the unwary that if they want lightweight exception handling in their Python/ML/whatever implementation they should use some other method. PS. Kenneth, why don't you just use setjmp/longjmp directly. Or, if you want, I can email you my lightweight versions if you want,

Hi Mark, > Can I suggest that invoke/unwind be renamed DWARF_invoke/DWARF_unwind to > warn the unwary that if they want lightweight exception handling in > their Python/ML/whatever implementation they should use some other method. probably there should be a switch to choose whether codegen should turn unwind/invoke into dwarf or setjmp/longjmp style code. Ciao, Duncan.

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

> > 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 wouldn't work, saying "if you throw an > exception

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

On Mon, Jul 20, 2009 at 11:18 AM, Duncan Sands<baldrick at free.fr> wrote: > Hi Mark, > >> You are confusing stopping the unwinding at *some* levels or at *all* >> levels. >> Eg. >> invoke >>   call >>    call >>     invoke >>      call >>       call >>        unwind > > the dwarf unwinder only stops and runs user code

Hi Kenneth, > Is there anything in the current codebase that maps an "unwind" > instruction to a DWARF unnwinder? Seeing as how (I think) the DWARF > info is already compiled in, this would be a useful thing. in llvm from svn an "unwind" instruction is mapped to a call to _Unwind_Resume. This is no good for throwing a new dwarf exception, but it does mean that you

Sweet! That is exactly what I've been looking for. I guess it's going in the 2.6 release then? And __cxa_throw will still throw a DWARF exception with the landing pads and the exception object selection and all that jazz? On Mon, Jul 20, 2009 at 12:12 PM, Duncan Sands<baldrick at free.fr> wrote: > Hi Kenneth, > >> Is there anything in the current codebase that maps an

Kenneth Uildriks wrote: > Sweet! That is exactly what I've been looking for. I guess it's > going in the 2.6 release then? Yes. You still need to call __cxa_throw (or equivalent) to throw a new exception, but you can now use unwind to rethrow an exception from the unwind block of an invoke. That said, I don't think anyone is making use of it - probably no-one except me even

Duncan Sands wrote: > Hi Mark, > >> So who is responsible for (as stated under the invoke description in the >> language reference) "ensure that proper cleanup is performed in the case >> of either a longjmp or a thrown exception"? > > the unwinder (however it works) needs to stop at each invoke and run > the code in the unwind block of the invoke. I

> Yes. You still need to call __cxa_throw (or equivalent) to throw > a new exception, but you can now use unwind to rethrow an exception > from the unwind block of an invoke. That said, I don't think anyone > is making use of it - probably no-one except me even knows about it :) I forgot to mention that for the moment you still need to specify the personality function using an

> I forgot to mention that for the moment you still need to specify > the personality function using an eh.selector.  That's because I > never got around to telling the code generators that if there is > none then it should use the C (not C++) personality. You only need that to throw an exception, not to do a simple unwind, right?

Hi Andrew, > pthread_cleanup_pop() is nothing special, it's just an example of a > cleanup handler. Cleanups are very similar to exception handlers, but > with one small difference: they do some work and then call > _Unwind_Resume() which continues unwinding. The unwinder itself > doesn't know anything about pthread cleanups, it just executes > whatever is at the

Duncan Sands wrote: >> pthread_cleanup_pop() is nothing special, it's just an example of a >> cleanup handler. Cleanups are very similar to exception handlers, but >> with one small difference: they do some work and then call >> _Unwind_Resume() which continues unwinding. The unwinder itself >> doesn't know anything about pthread cleanups, it just executes

> Yes. Wasn't that obvious? Sorry, I don't understand what point you're > trying to make. I noticed that some people (not you) seem to think that the dwarf unwinder knows special things about signals, pthread_cleanup_pop and whatnot. I was just trying to say that it does not: all this stuff is covered by the standard exception handling concepts. Ciao, Duncan

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

On Tue, Jul 21, 2009 at 10:09 AM, Duncan Sands<baldrick at free.fr> wrote: >> Yes.  Wasn't that obvious?  Sorry, I don't understand what point you're >> trying to make. > > I noticed that some people (not you) seem to think that the dwarf > unwinder knows special things about signals, pthread_cleanup_pop > and whatnot.  I was just trying to say that it