From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29984 invoked by alias); 29 Dec 2004 07:39:32 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 29951 invoked from network); 29 Dec 2004 07:39:22 -0000 Received: from unknown (HELO thoreau.thistledown.com.au) (203.217.30.154) by sourceware.org with SMTP; 29 Dec 2004 07:39:22 -0000 Received: from thoreau.thistledown.com.au (localhost [127.0.0.1]) by thoreau.thistledown.com.au (Postfix) with ESMTP id 8EEE02356C; Wed, 29 Dec 2004 18:39:19 +1100 (EST) From: Simon Burge Organization: Wasabi Systems, Inc. To: Ian Lance Taylor Cc: binutils@sources.redhat.com Subject: Re: .eh_frame section on alpha In-Reply-To: Your message of "24 Dec 2004 09:59:58 -0500 " Date: Wed, 29 Dec 2004 07:39:00 -0000 Message-Id: <20041229073919.8EEE02356C@thoreau.thistledown.com.au> X-SW-Source: 2004-12/txt/msg00328.txt.bz2 Hi Ian, Ian Lance Taylor wrote: > Simon Burge writes: > > > http://sources.redhat.com/ml/binutils/2003-05/msg00863.html added the > > generation of a .eh_frame section to all objects that otherwise didn't > > have them. > > > > On NetBSD, we have some tight code size constraints for our first stage > > boot loader - it needs to fit in 7.5k of space at the start of the disk. > > With binutils 2.14, our boot loader was 6880 bytes. With binutils 2.15, > > the boot loader is 7848. The only difference in size between the two is > > the .eh_frame section: > > > > 3 .eh_frame 000003c4 0000000020001990 0000000020001990 00001a40 2**3 > > CONTENTS, ALLOC, LOAD, READONLY, DATA > > > > What exactly is this section used for? A bit of googling seems to > > indicate it's for exception handling, which isn't a C issue. > > > > More importantly, how can I disable the generation of this section? It > > seems that only alpha generates an .eh_frame section unconditionally. > > Hi Simon. I haven't tested it, but there should be two ways to > disable to automatic creation of the .eh_frame section: 1) do not emit > the directives which create one--.ent, .end, .frame, etc.; 2) create > your own .eh_frame section and put nothing in it--for example, the > assembler doesn't generate its own unwind information for compiled > code, because the compiler creates a .eh_frame section anyhow. This worked, but was difficult to make sure all objects got to include a dummy .eh_frame section. For now, James Chacon has come up with a change to our make rules for .{c,S,s}->.o builds that just calls "objcopy -R .eh_frame". This at least doesn't need any code changes and is quite a local change. Simply removing the .eh_frame section from the final linked object didn't work, since we use "objcopy --output-target=binary" to make a blob to put on disk and just removing the .eh_frame section at this stage left a hole in the file (ie, text started at the same address and data finished at the same address but the area where the .eh_frame section was in the middle was now just zero'ed out). > However, I also think it would be a good idea to have an assembler > option to not create the unwind information. Strongly agreed :-) I can come up with a patch, but I'm not sure what a good option name would be. --no-auto-eh-frame seems a little unwieldy. Simon. -- Simon Burge NetBSD Support and Service: http://www.wasabisystems.com/