From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28659 invoked by alias); 28 Nov 2003 12:35:25 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 28622 invoked from network); 28 Nov 2003 12:35:24 -0000 Received: from unknown (HELO cam-admin0.cambridge.arm.com) (193.131.176.58) by sources.redhat.com with SMTP; 28 Nov 2003 12:35:24 -0000 Received: from pc960.cambridge.arm.com (pc960.cambridge.arm.com [10.1.205.4]) by cam-admin0.cambridge.arm.com (8.12.10/8.12.10) with ESMTP id hASCZMbo005658; Fri, 28 Nov 2003 12:35:23 GMT Received: from pc960.cambridge.arm.com (rearnsha@localhost) by pc960.cambridge.arm.com (8.11.6/8.9.3) with ESMTP id hASCZM927688; Fri, 28 Nov 2003 12:35:22 GMT Message-Id: <200311281235.hASCZM927688@pc960.cambridge.arm.com> X-Authentication-Warning: pc960.cambridge.arm.com: rearnsha owned process doing -bs To: Daniel Jacobowitz cc: Richard.Earnshaw@arm.com, Jim Wilson , gcc-patches@gcc.gnu.org Reply-To: Richard.Earnshaw@arm.com Organization: ARM Ltd. X-Telephone: +44 1223 400569 (direct+voicemail), +44 1223 400400 (switchbd) X-Fax: +44 1223 400410 X-Address: ARM Ltd., 110 Fulbourn Road, Cherry Hinton, Cambridge CB1 9NJ. X-Url: http://www.arm.com/ Subject: Re: avoid unnecessary register saves for setjmp In-reply-to: Your message of "Sat, 22 Nov 2003 11:26:54 EST." <20031122162654.GA6032@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Nov 2003 14:02:00 -0000 From: Richard Earnshaw X-SW-Source: 2003-11/txt/msg02240.txt.bz2 > > In the EABI we've been developing for the ARM we've been very careful to > > say that only the setjmp and longjmp functions can know the contents and > > layout of a jmp_buf. This allows a function to use co-processor registers > > that are call saved and to be used in the middle of a call sequence > > without upsetting any other conforming code. Hence only the C library > > needs to know the list of co-processors that are in use (and it is > > entitled to enter into other private conspiracies to determine the > > registers that need to be saved. We've even designed the EH > > implementation in a way that will allow this to work as well (the unwinder > > will only try to execute instructions to access a particular co-processor > > once it has found a description of that co-processor in the unwind list). > > How do you intend to implement this in practice? I'm not concerned > with the contents or layout of a jmp_buf; conforming programs can't get > at them. But user programs declare jmp_buf, which implies that they > know its size. And there's no way I can think of to dynamically > allocate additional space if the jmp_buf is insufficiently large. > Are you simply defining a very large jmp_buf for expansion? > > This is the problem I encountered on both PowerPC and ARM. I'm very > curious to hear any solutions to it. There's never a perfect solution to a situation like this. The failure of history (and more recently of language standards bodies) to recognize that portable binaries have as much importance as portable source means that in the dark corners you are always doomed to failure. The way we've approached the issue for the "ABI for the ARM Architecture" is to define a compliance model. The model is fairly simple and basically divides into 2 categories. In the "portable object" category, the trade-off is in the direction of portability over outright compliance to the language standards and performance. Sometimes it's necessary to write your source code using a particular idiom in order to achieve maximum portability. In other cases constants that the C standard says are compile-time literals may only be available as link-time constants. You are also restricted as to the library functions you may call. In general, for example, you can't include stdio.h in a portable object and have it do anything useful. We believe that developers targeting the portable-objects market will be prepared to live with the restrictions because it's better than anything they could have otherwise. In the "platform object" category, the trade-off is in the direction of compliance to the relevant standards. You can use the full features of the language, but your object is tied to a particular platform. setjmp is one of those functions that lies on the boundary between the two models. If you are compiling for a particular platform, which has a strict ABI, then you can use a jmp_buf that is exactly right for that platform. But if you are building a portable object, you have to be prepared to handle platforms with a lot of registers that need saving and restoring; it is however, possible to err on the side of caution and just say that any static jmp_buf must be at least as large as the jmp_buf used by any supported target system. For a dynamic jmp_buf, if you are prepared to use dynamic allocation, and to use source-code modifications, then we've added a link-time constant that will tell you the exact size needed for the platform the code ends up running on. As for the portable static size of a jmp_buf, we looked at the likely register needs given the current co-processor blocks in existence today, and concluded that we currently should allow for 32 double-words of memory (256 bytes, 8-byte aligned) for the buffer. We've no proof that we will never need more, but sometimes you just have to make a judgement call. We'd recommend that developers defining new open-platform ABIs use the portable size, since it then gives them maximum defence against future processor trends. R. Disclaimer: the ABI for the ARM Architecture" is still in draft form, so any specifics cited above may still be subject to change. I don't expect them to, but the possibility does exist.