From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19486 invoked by alias); 19 May 2011 17:10:08 -0000 Received: (qmail 19282 invoked by uid 22791); 19 May 2011 17:10:04 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-iw0-f169.google.com (HELO mail-iw0-f169.google.com) (209.85.214.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 19 May 2011 17:09:45 +0000 Received: by iwg8 with SMTP id 8so3176338iwg.0 for ; Thu, 19 May 2011 10:09:44 -0700 (PDT) Received: by 10.42.208.201 with SMTP id gd9mr850285icb.417.1305824961287; Thu, 19 May 2011 10:09:21 -0700 (PDT) Received: from chips-computer.local (71-211-63-128.clsp.qwest.net [71.211.63.128]) by mx.google.com with ESMTPS id xe15sm1052858icb.20.2011.05.19.10.09.18 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 May 2011 10:09:19 -0700 (PDT) Message-ID: <4DD54EBD.9050704@mymail.mines.edu> Date: Thu, 19 May 2011 17:10:00 -0000 From: Charles Davis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kai Tietz CC: binutils@sourceware.org Subject: Re: Proposal for Win64 exception handling directives References: <4DD45235.5070300@mymail.mines.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2011-05/txt/msg00285.txt.bz2 On 5/18/11 11:52 PM, Kai Tietz wrote: > 2011/5/19 Charles Davis : >> (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 [, ] >> >> Delimits the beginning of a function callable from that has >> unwind data. If 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 , >> >> Specifies the location and 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 >> >> Specifies that the non-volatile is pushed onto the stack. >> Equivalent to MASM's .pushreg directive. >> >> - .w64_setframe , >> >> 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 >> >> Specifies that some stack space was allocated. Equivalent to MASM's >> .allocstack directive. >> >> - .w64_savereg , >> >> Specifies that the was saved at an 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