This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Exception causing insns in delay slots


   From: Jason Merrill <jason@redhat.com>
   Date: Fri, 26 Apr 2002 12:15:30 +0100

   > Ok, this seems to doubly confirm the need for my reorg fix.
   
   I wouldn't expect trapping instructions to have any unwind information
   impact, except that the unwind info needs to be correct when we reach them.
   This would only be a problem if the trapping insn is scheduled in the
   delay slot of an insn which adjusts the stack.  I could imagine that being
   true of some sort of combined call-push insn, but I'm not aware of any such
   beast, certainly not on a target with delay slots.

We don't emit the notes properly.  When reorg puts an exception
causing instruction into a delay slot, and that instruction is the
only exception causing instruction in that particular exception
region, we currently don't emit the notes correctly.  My original
email of this thread shows the details around this.

That is the problem.

The safe fix for that is the reorg changes.

Even if it could emit the notes properly, we couldn't unwind to
the sucker correctly.  This is because of all the "current->ra - 1"
buisness and the assumption (which you mentioned) of the code stream
being linear.

Tell me which part isn't making sense and I'll try to elaborate
further.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]