Re: Proposal for Win64 exception handling directives

[Kai Tietz <ktietz70@googlemail.com>]

2011/5/19 Charles Davis <cdavis@mymail.mines.edu>:
> (Since I'm not subscribed to this mailing list, please reply to all when
> replying.)
>
> Hi,
>
> My name is Chip Davis, and I'm working on adding support for Win64-style
> exception handling to LLVM (at the behest of several people). I know
> there's interest in adding similar support to GCC.
>
> Right now, I'm working on assembler-level directives for emitting the
> required data for Win64-style exception handling. Since LLVM's
> integrated assembler was designed to be compatible with GAS, I'm writing
> you this message to make sure we're on the same page.
>
> So, in no particular order, here are the directives that I propose for
> emitting Win64 unwind data from the assembler. They're loosely based on
> MASM's directives, but augmented to support compilers such as Clang and GCC.
>
> - .w64_startproc <symbol> [, <ehandler>]
>
> Delimits the beginning of a function callable from <symbol> that has
> unwind data. If <ehandler> is specified, it is an exception handler to
> be used for this function (or an unwind handler; see below). Roughly
> equivalent to MASM's FRAME attribute on procedures.
>
> - .w64_endproc
>
> Delimits the end of a function with unwind data. MASM has no such
> directive, but it doesn't need it since it delimits functions with PROC
> and ENDP. We need it because GAS (and subsequently, LLVM) has no such
> mechanism.
>
> - .w64_startchained
>
> Starts an area of a function with additional operations to be undone in
> case of an exception. The unwind info struct is chained to the parent
> function. MASM has no equivalent; its support wasn't really designed for
> compilers.
>
> - .w64_endchained
>
> Ends an area of a function with additional operations to be undone in
> case of an exception. MASM has no equivalent; its support wasn't really
> designed for compilers.
>
> - .w64_unwind_only
>
> Indicates that this function doesn't handle any exceptions. If it has a
> handler specified in .w64_startproc, it is an unwind handler instead of
> an exception handler.
>
> MASM has no equivalent; its support wasn't really designed for compilers.
>
> - .w64_lsda <symbol>, <size>
>
> Specifies the location and <size> of the Language-Specific Data Area
> (LSDA). In Win64 EH, the LSDA is stored in the unwind info structure
> itself; the data will be copied into it upon emission.
>
> MASM has no equivalent; its support wasn't really designed for compilers.
>
> - .w64_pushreg <register>
>
> Specifies that the non-volatile <register> is pushed onto the stack.
> Equivalent to MASM's .pushreg directive.
>
> - .w64_setframe <regsiter>, <offset>
>
> Specifies the frame pointer register, and the offset (as a multiple of
> 16) from the stack pointer when the frame pointer is established.
> Equivalent to MASM's .setframe directive, and similar to the
> .cfi_def_cfa DWARF CFI directive.
>
> - .w64_allocstack <size>
>
> Specifies that some stack space was allocated. Equivalent to MASM's
> .allocstack directive.
>
> - .w64_savereg <register>, <offset>
>
> Specifies that the <register> was saved at an <offset> relative to the
> executable's base address. Only non-volatile registers should be
> indicated here. Equivalent to both MASM's .savereg and .savexmm128
> directives; I felt there was no need for a separate directive for XMM
> registers.
>
> - .w64_pushframe [code]
>
> Specifies that this is an interrupt handler. On x86-64, interrupt
> handlers have the original far stack pointer (SS:RSP), flags, and far
> program counter (CS:RIP) pushed onto the stack upon entry. If [code] is
> present, there is an error code on the stack in addition to the standard
> data. Equivalent to MASM's .pushframe directive.
>
> - .w64_endprolog
>
> Delimits the end of the function prolog. After this directive, no Win64
> EH directives other than a .w64_endproc (or .w64_endchained, if this is
> a chained unwind area) may appear. Equivalent to MASM's .endprolog
> directive.
>
> Comments and suggestions are welcome. (And please, no licensing flame
> wars.) Thanks for your time.
>
> Chip

Chip,

well, what you want to do here is already done fot binutils. Please
see in gas/condig/obj-coff-seh.c for the implementation of
pseudo-codes for SEH

Regards,
Kai