[ros-dev] [ros-diffs] [hyperion] 38461: modified tests/pseh2/psehtest.c finally_13 test re-enabled, as it doesn't crash anymore finally_14 test fixed. Now we know how exceptions thrown in a __finally are supposed to be handled PSEH test suite now has 91 tests and passes all of them with both GCC and Visual C++

[Timo Kreuzer]

KJK::Hyperion wrote:
> Timo Kreuzer wrote:
>   
>> 1.) All used variables are static. That means the optimizer is mostly
>> out of the game.
>>     
>
> It's intentional. Using functions instead of constants is intentional,
> too. Ensures variables are actually instanced, even if they are
> "unused". And PSEH macros have slightly different behavior when
> compile-time constants are used in some places. I'm unsure how to test
> *reliably* interactions between optimizer bugs and PSEH
>   
I just suggest testing real situations instead of hypothetical
situations. And it's a fact that we normally don't use static variables
and bot only functions but also constants in our code. So these tests
are of small value regarding the usage in reactos. And you shouldn't
simply blame the optmimizer to have bugs when it doesn't do what you
would like it to do.

>   
>> So I did some testing. After removing the static, I got 1 error:
>> psehtest.c:2490: Test failed: test_continue_search_3 failed
>>     
>
> The return value of return_positive() is not stored anywhere, and ret
> remains uninitialized. Congratulations! you found a compiler bug
>   
No, it's a valid optimisation:
1. The return value of return_positive() is stored in edx
2. The code branches into the 1st try and except block
  2a) except block (will not be called here): edx is put on the stack,
return_arg() is called and the result copied to ebx
  2b) try block: again 2 different branches, in both of them
return_zero() is called and the result stored in ebx
3.) ebx is compared to the return value of return_positive()

The compiler generates a new instance of the ret variable each time it's
assigned and it's free to use different registers and/or memory
locations each time, as long as it stays consistent for each possible
code path.

The test fails, because when executing the exception block, edx doesn't
contain what it should, as it's zeroed in the try block before the
exception happens. Exceptions are simply not considered as possible code
pathes.
This can and will happen unless
a) We require that all variables that are changed inside a try block and
referenced inside the except block must be declared volatile
b) We find a way to tell gcc to not change the location of a variable
during a try block.

>   
>> After replacing the return_x, ... functions with macros I got 3 errors:
>>     
>
> I don't. Send me your modifications
>   
I attached 2 patches.

Regards,
Timo



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.reactos.org/pipermail/ros-dev/attachments/20081230/f65a693f/attachment-0001.html 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pseh2_test.patch
Url: http://www.reactos.org/pipermail/ros-dev/attachments/20081230/f65a693f/attachment-0002.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pseh2_test_2.patch
Url: http://www.reactos.org/pipermail/ros-dev/attachments/20081230/f65a693f/attachment-0003.pl