[Mono-list] RE: Questions

[Neale.Ferguson@SoftwareAG-USA.com]

Hi again,
 The question of exception handling has just arised as I run some more =
tests for S/390. For example, if I handle and exception and need to call =
a filter where I have to restore the stack pointer to the frame where =
the "finally" exists. If this bit of code then issues its own calls then =
it's going to trample over the frames that come after it (that are still =
active like the exception handler's). For example, on S/390 where the =
frame grows down if the filter uses frame A and the exception handler =
gets invoked (eventually) and uses frame C then if the "finally" is =
invoked with frame A if it issues its own calls then frame B/C could get =
trampled.=20

*----------------*
| Stack frame A  |
*----------------*
| Stack frame B  |
*----------------*
| Stack frame C  |
*----------------*

As a concrete example, take exception15.cs:

using System;

class Tests {
        public static int Main(){
                int i =3D 0;
                try{
                        try {
                                throw new NotImplementedException();
                        }
                        finally {
                                i++;
                                Console.WriteLine("Finally called");
                        }
                } catch(NotImplementedException){
                        i++;
                        Console.WriteLine("Exception ignored");
                }

                if (i !=3D 2)
                        return 1;

                return 0;
        }
}

If the exception handler gets involved, discovers the catch, calls the =
call_filter routine which branches to the finally after restoring the =
registers to the context of Main. Now, this finally requires access to =
its entire stack frame as it references the variable "i". However, it =
then issues a Console.WriteLine which means new stack frames appearing =
after its own. Therefore, when it returns to the "call_filter" routine =
it's possible that the stack frame of this routine has been trashed by =
the calls made in the finally stuff.

Now considering this works for all the other platforms then I must be =
doing something incorrectly or the ABI for S/390 makes things =
problematic for me.

Neale