Re: Proposal for Win64 exception handling directives

[Charles Davis <cdavis at mymail dot mines dot edu>]

On 5/18/11 11:52 PM, Kai Tietz wrote:
> 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
Thanks for that.

Chip