This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problem with x64 SEH macro implementation for ReactOS


Kai Tietz writes:
>Hmm, yes and no. First the exception handler uses the .pdata and .xdata 
>section for checking throws. But there is still the stack based exception 
>mechanism as for 32-bit IIRC. 

No.  The mechanism is completely different.  The whole point of the unwind
tables is to remove the overhead of maintaining the linked list of records
on the stack.  It works just like DWARF2 exceptions in this respect.

>No, this isn't that curious as you mean. In the link you sent me, it is 
>explained. The exception handler tables (.pdata/.xdata) are optional and 
>not necessarily required.

This is what Microsoft's documentation says:

	Every function that allocates stack space, calls other functions,
	saves nonvolatile registers, or uses exception handling must
	have a prolog whose address limits are described in the unwind
	data associated with the respective function table entry.

In this very limited case RtlUnwindEx() can indeed unwind a function
without it having any unwind info associated with it.  If RtlUnwindEx()
can't find the unwind data for a function then it assumes that the
stack pointer points directly at the return address.  To unwind through
the function it pops the top of stack to get the next frame's RIP and
RSP values.  Otherwise RltUnwindEx() needs the unwind information.

The restrictions on the format of prologue and epilogue only exist to
making handle the case where the current RIP points to the prologue or
epilogue much easier.  Without the unwind info RtlUnwindEx() has no way
of knowing where the prologue is.

There's a very detailed explaination on how Windows x64 exceptions work,
including RltUnwindEx() on this blog:

	http://www.nynaeve.net/?p=113

>But in general I agree, that the generation of .pdata/.xdata sections 
>would be a good thing for better support of MS abis by gcc.

I'm not advocating that they should be added to GCC now.  I'm just
pointing out that without them 64-bit SEH macros will be of limitted use.

				Ross Ridge


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]