Re: [perl #44391] r19820 breaks other JITs
On 05/08/07, Joshua Isom <[EMAIL PROTECTED]> wrote: > > On Aug 4, 2007, at 5:28 AM, Paul Cochrane wrote: > > > On 03/08/07, via RT Joshua Isom <[EMAIL PROTECTED]> > > wrote: > >> # New Ticket Created by Joshua Isom > >> # Please include the string: [perl #44391] > >> # in the subject line of all future correspondence about this issue. > >> # http://rt.perl.org/rt3/Ticket/Display.html?id=44391 > > >> > >> > >> After a fair amount of headaches, I finally discovered some of my > >> trouble with my jit. It seems as though r19820 changed the API for > >> preserving and restoring parrot's registers to cpu registers. The > >> cause was to convert internal_exceptions(fatal) to > >> real_exceptions(maybe fatal), and since internal_exceptions need > >> interp, interp gets passed around. Only i386 was fixed to handle the > >> API change, and PPC's broken. In this case, real_exception could be > >> appropriate to prevent executing bad/incomplete machine code that > >> would > >> crash parrot. If you look at the exceptions used, in i386's > >> jit_emit.h, it's more a bad jit_emit.h than anything caused by a user. > > > > Since I was unable to test the internal_exception() to > > real_exception() change on anything other than i386, I didn't update > > the jit_emit.h headers for other architectures in the repository. I'm > > sorry that this has caused headaches. I did make a mention of the > > fact that I couldn't update all architectures in RT#40392 which I'm > > pretty sure made it to the list. Is there anything I can do to help > > out? > > > > Paul > > Part of my what I was thinking was that many of those > internal_exceptions should probably stay internal_exceptions because it > means one of the macros or subs was used incorrectly and tried to > generate invalid code. The way I see it, internal_exceptions should > never be generated from PIR code, and most likely indicate improper > usage of some part of parrot, and real_exceptions can be generated from > PIR code and may wish to be caught. I don't mind if some of the real_exceptions return to internal_exceptions, so long as this is the right thing to do.
Re: [perl #44391] r19820 breaks other JITs
On Aug 4, 2007, at 5:28 AM, Paul Cochrane wrote: On 03/08/07, via RT Joshua Isom <[EMAIL PROTECTED]> wrote: # New Ticket Created by Joshua Isom # Please include the string: [perl #44391] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=44391 > After a fair amount of headaches, I finally discovered some of my trouble with my jit. It seems as though r19820 changed the API for preserving and restoring parrot's registers to cpu registers. The cause was to convert internal_exceptions(fatal) to real_exceptions(maybe fatal), and since internal_exceptions need interp, interp gets passed around. Only i386 was fixed to handle the API change, and PPC's broken. In this case, real_exception could be appropriate to prevent executing bad/incomplete machine code that would crash parrot. If you look at the exceptions used, in i386's jit_emit.h, it's more a bad jit_emit.h than anything caused by a user. Since I was unable to test the internal_exception() to real_exception() change on anything other than i386, I didn't update the jit_emit.h headers for other architectures in the repository. I'm sorry that this has caused headaches. I did make a mention of the fact that I couldn't update all architectures in RT#40392 which I'm pretty sure made it to the list. Is there anything I can do to help out? Paul Part of my what I was thinking was that many of those internal_exceptions should probably stay internal_exceptions because it means one of the macros or subs was used incorrectly and tried to generate invalid code. The way I see it, internal_exceptions should never be generated from PIR code, and most likely indicate improper usage of some part of parrot, and real_exceptions can be generated from PIR code and may wish to be caught.
Re: [perl #44391] r19820 breaks other JITs
On 03/08/07, via RT Joshua Isom <[EMAIL PROTECTED]> wrote: > # New Ticket Created by Joshua Isom > # Please include the string: [perl #44391] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt3/Ticket/Display.html?id=44391 > > > > After a fair amount of headaches, I finally discovered some of my > trouble with my jit. It seems as though r19820 changed the API for > preserving and restoring parrot's registers to cpu registers. The > cause was to convert internal_exceptions(fatal) to > real_exceptions(maybe fatal), and since internal_exceptions need > interp, interp gets passed around. Only i386 was fixed to handle the > API change, and PPC's broken. In this case, real_exception could be > appropriate to prevent executing bad/incomplete machine code that would > crash parrot. If you look at the exceptions used, in i386's > jit_emit.h, it's more a bad jit_emit.h than anything caused by a user. Since I was unable to test the internal_exception() to real_exception() change on anything other than i386, I didn't update the jit_emit.h headers for other architectures in the repository. I'm sorry that this has caused headaches. I did make a mention of the fact that I couldn't update all architectures in RT#40392 which I'm pretty sure made it to the list. Is there anything I can do to help out? Paul
[perl #44391] r19820 breaks other JITs
# New Ticket Created by Joshua Isom # Please include the string: [perl #44391] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=44391 > After a fair amount of headaches, I finally discovered some of my trouble with my jit. It seems as though r19820 changed the API for preserving and restoring parrot's registers to cpu registers. The cause was to convert internal_exceptions(fatal) to real_exceptions(maybe fatal), and since internal_exceptions need interp, interp gets passed around. Only i386 was fixed to handle the API change, and PPC's broken. In this case, real_exception could be appropriate to prevent executing bad/incomplete machine code that would crash parrot. If you look at the exceptions used, in i386's jit_emit.h, it's more a bad jit_emit.h than anything caused by a user.
