Re: [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 schrieb:
>   Timo Kreuzer wrote:
>    
> >   In other words the register *is dead* on entering
> > the try branch.
> >       
>  Read and compare the disassembled code of continue_search_3 before and
>  after my last change
>     
Yes, it's fixed now. At least this case. It's still not the holy grail
I
think.

What about this one:

DEFINE_TEST(set_before_exception)
{
    int ret1, ret2;

    ret2 = ret1 = 0;

    _SEH2_TRY
    {
        ret2 = 1;
        volatile char * p = 0;
        *p = 0;
        ret1 = 1;
    }
    _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER)
    {
        ret1 = -1;
    }
    _SEH2_END;

    return (ret1 == -1 && ret2 == 1);
}

The compiler assumes that on entering the except block, that not a
single instruction of the try block has been executed. And it will use
this to optimize away everything it can. MSVC will preserve the
instruction order and make sure all variables are stored in memory
locations.
I don't think you can get this handled equally without hacking it into gcc.

This case isn't that bad. We just have the following requirement:
Do not make any assumptions about the order in which code is executed
inside the try block!
Not even if normally you could say that something must be executed in a
special order (like x = func1(); y = func2(x);)

But there's another thing that bothers me. It's guaranteed that all
variables that are used after the call to _SEH2EnterFrame are either
constants or stored in a memory location at the time that SEH2EnterFrame
is called. No more, no less. It is not guaranteed that the variables
stay there.
Now the compiler could decide to move a variable into a register
directly after the call (maybe because it's needed in this register in
both branches) and before the branch. Then in the try branch later it's
moved into another register just before the exception occurs.

Now this is hypothetical, because I couldn't find a real situation where
this happens. I just think it might be possible.

Regards,
Timo