This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: .eh_frame section on alpha
- From: Simon Burge <simonb at wasabisystems dot com>
- To: Ian Lance Taylor <ian at airs dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Wed, 29 Dec 2004 18:39:19 +1100
- Subject: Re: .eh_frame section on alpha
- Organization: Wasabi Systems, Inc.
Hi Ian,
Ian Lance Taylor wrote:
> Simon Burge <simonb@wasabisystems.com> 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 <simonb@wasabisystems.com>
NetBSD Support and Service: http://www.wasabisystems.com/