On Fri, 03 Apr 2009 08:00:33 +0100, Dave Korn
<dave.korn.cyg...@googlemail.com> wrote:
> Cary Coutant wrote:
>>> With SEH you can catch that kind of errors and that's why it's so
>>> interesting in embedded world
>>
>> That's also why SEH is a major pain for optimization. The compiler
>> would have to identify every instruction that may trigger an
>> exception,
>
> Isn't that what the "__try" block scope is there to tell you? Or are
you
> considering if it were to be done automatically?
>
I agree with Dave I don't understand why compiler would have to identify
every instruction.
__try __except blocks register ranges in which an exception could be
raised.
I didn't want to go in details but I have simplified my explanation a lot
about table-based SEH.
There are several levels, the first one is the function level and as I
wrote, a table
(IMAGE_CE_RUNTIME_FUNCTION_ENTRY in my case) stores
information about every function in code and especially its lenght, its
prologue lenght
and if it uses SEH.
So if an exception is raised, first OS just need to look at current address
and to find in table
if the function is protected by SEH.
Then in this case another table stores __try __except boundaries :
typedef struct _SCOPE_TABLE {
ULONG Count; // number of items
struct
{
ULONG BeginAddress; // start of __try block
ULONG EndAddress; // end of __try block
ULONG HandlerAddress; // filter function
ULONG JumpTarget; // code inside __except
} ScopeRecord[1];
} SCOPE_TABLE, *PSCOPE_TABLE;
So next if faulty address is between BeginAddress and EndAddress, crt call
filter function to know
if it wants to handle this exception and if it returns
EXCEPTION_EXECUTE_HANDLER then there's a jump
at JumpTarget.
Once again what I describe above is simplified because when seh is used,
there is a mechanism
called virtual unwiding that I didn't explained but that is the reason to
store the prologue length.
>> On top of that, the filters can return a code that tells the EH
>> mechanism to resume execution at the original exception point as if
>> nothing happened. Just trying to understand all the implications of
>> that makes my head hurt.
>
> For background reading, the Matt Pietrek win32 SEH article would be the
> canonical source. (Don't have the URL to hand but those words should
> google
> it straight up for you).
>
> Really, it's all pretty much the same as DW2, except that rather than
> calling a raise exception function in libgcc, it begins with a real
> processor
> exception that then ends up routing into the unwinder. From there it's
all
> fairly analagous.
>
Yes this article is the best one about frame-based SEH (x86) but there are
also very good one
about table-based (x64, arm, mips, sh).
http://www.microsoft.com/msj/0197/Exception/Exception.aspx : frame-based
exception
In google type : x64 seh and select first entry (cached version only
available)
http://www.nynaeve.net/?p=99
http://www.howzatt.demon.co.uk/articles/oct04.html
http://www.ntcore.com/Files/vista_x64.htm#Exception_Handling
http://www.smartmobili.com/content/view/40/42/lang,fr/
...
Please note that SEH is also the underlying mechanism used by C++
exceptions on windows platforms.
