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.
*----------------*
| 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 = 0;
try{
try {
throw new NotImplementedException();
}
finally {
i++;
Console.WriteLine("Finally called");
}
} catch(NotImplementedException){
i++;
Console.WriteLine("Exception ignored");
}
if (i != 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
_______________________________________________
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
