Proposal for Win64 exception handling directives

[Charles Davis <cdavis at mymail dot mines dot 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