Re: widl [1/7]: Output working exception handling macros. [take 3]
Dan Hipschman <dsh(a)linux.ucla.edu> writes:
In this revision, I leave setting permissions on page faults to the unhandled exception filter and simply ignore page faults on execution access (read access exceptions should be caught since they translate into bad stub data, but these don't pose a problem anyway). I also fixed a bug regarding how the mask field of __widl_except_frame was set.
There's no reason to ignore execute access errors, those are bugs too. You are still not filtering the exception properly though, the condition checking has to be done directly in the handler, you can't longjmp back to the code and then re-raise the exception. That's doubly true for the finally handling. This means you have to generate different handlers for the different exception conditions. -- Alexandre Julliard julliard(a)winehq.org
On Thu, Nov 29, 2007 at 02:57:50PM +0100, Alexandre Julliard wrote:
Dan Hipschman <dsh(a)linux.ucla.edu> writes:
In this revision, I leave setting permissions on page faults to the unhandled exception filter and simply ignore page faults on execution access (read access exceptions should be caught since they translate into bad stub data, but these don't pose a problem anyway). I also fixed a bug regarding how the mask field of __widl_except_frame was set.
There's no reason to ignore execute access errors, those are bugs too. You are still not filtering the exception properly though, the condition checking has to be done directly in the handler, you can't longjmp back to the code and then re-raise the exception. That's doubly true for the finally handling. This means you have to generate different handlers for the different exception conditions.
That's basically what I did in the original patch using __TRY/__EXCEPT/__FINALLY. You told me to do this in a more straightforward way: http://www.winehq.org/pipermail/wine-devel/2007-November/060515.html which I took to mean trying to implement the finally block as an actual block in the local scope, instead of a function (which is a bit of a pain). I don't see any way to execute the finally block in the local scope without rethrowing exceptions, or using GCC's nested functions. The except condition is easier to put into a handler since the only conditions WIDL generates are pretty simple. Should I go back to the original patch? How did you want it different?
Dan Hipschman <dsh(a)linux.ucla.edu> writes:
That's basically what I did in the original patch using __TRY/__EXCEPT/__FINALLY. You told me to do this in a more straightforward way:
http://www.winehq.org/pipermail/wine-devel/2007-November/060515.html
which I took to mean trying to implement the finally block as an actual block in the local scope, instead of a function (which is a bit of a pain). I don't see any way to execute the finally block in the local scope without rethrowing exceptions, or using GCC's nested functions. The except condition is easier to put into a handler since the only conditions WIDL generates are pretty simple.
Should I go back to the original patch? How did you want it different?
I said you should avoid the convoluted macros and the dependencies on internal Wine functions, since you can generate the code directly. That doesn't mean you can change the semantics, you really need to filter the exception type in the handler. And yes, the finally block most likely needs to be a separate function; that is a bit complicated so I'd suggest to start with just exceptions for now and get this one right first. -- Alexandre Julliard julliard(a)winehq.org
participants (2)
-
Alexandre Julliard -
Dan Hipschman