.eh_frame section on alpha

.eh_frame section on alpha

[Simon Burge]

Hi folks,

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.

Cheers,
Simon.
--
Simon Burge                                   <simonb@wasabisystems.com>
NetBSD Development, Support and Service:   http://www.wasabisystems.com/

Re: .eh_frame section on alpha

[Ian Lance Taylor]

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.

However, I also think it would be a good idea to have an assembler
option to not create the unwind information.

Ian

Re: .eh_frame section on alpha

[Simon Burge]

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/

Re: .eh_frame section on alpha

[Nick Clifton]

Hi Simon,

>>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.

How about: --no-create-eh-frame ?

I see no problem with long switch names.  It is better that they are 
expressive and tell the user what they are doing.  Shorter, more compact 
switch names are often confusing and can lead to user misunderstanding.

Cheers
   Nick

Re: .eh_frame section on alpha

[Jakub Jelinek]

On Tue, Jan 04, 2005 at 09:43:25AM +0000, Nick Clifton wrote:
> Hi Simon,
> 
> >>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.
> 
> How about: --no-create-eh-frame ?
> 
> I see no problem with long switch names.  It is better that they are 
> expressive and tell the user what they are doing.  Shorter, more compact 
> switch names are often confusing and can lead to user misunderstanding.

Can't this be done already without adding new options with a
/DISCARD/ : { *(.eh_frame) }
in the linker script?

	Jakub

Re: .eh_frame section on alpha

[Nick Clifton]

Hi Jakub,

> Can't this be done already without adding new options with a
> /DISCARD/ : { *(.eh_frame) }
> in the linker script?

Presumably yes.  But I assume that the feeling is that invoking an 
assembler switch is simpler for the user than requiring them to write or 
edit linker scripts.

Cheers
   Nick

Re: .eh_frame section on alpha

[Richard Henderson]

On Tue, Jan 04, 2005 at 10:14:03AM +0000, Nick Clifton wrote:
> Presumably yes.  But I assume that the feeling is that invoking an 
> assembler switch is simpler for the user than requiring them to write or 
> edit linker scripts.

If you're writing boot loaders, you're already writing linker scripts.


r~

Re: .eh_frame section on alpha

[Simon Burge]

On Tue, Jan 04, 2005 at 09:51:11AM -0800, Richard Henderson wrote:

> On Tue, Jan 04, 2005 at 10:14:03AM +0000, Nick Clifton wrote:
> > Presumably yes.  But I assume that the feeling is that invoking an 
> > assembler switch is simpler for the user than requiring them to write or 
> > edit linker scripts.
> 
> If you're writing boot loaders, you're already writing linker scripts.

We currently don't use a linker script.  Here's the complete linker
line:

alpha--netbsd-ld -Ttext 0x20000000 -N -e start -o bootxx_ffs.sym \
  start.o bootxx.o booted_dev.o blkdev.o prom.o prom_disp.o putstr.o \
  panic_putstr.o lib/sa/libsa.a kern/libkern.a -Map bootxx_ffs.map

Since we don't already use (and therefore have to maintain) a separate
linker script, a command line option to not generate these new .eh_frame
sections seems like the cleanest solution to me.

Cheers,
Simon.
--
Simon Burge                                   <simonb@wasabisystems.com>
NetBSD Development, Support and Service:   http://www.wasabisystems.com/

Re: .eh_frame section on alpha

[Jakub Jelinek]

On Wed, Jan 05, 2005 at 08:27:20AM +1100, Simon Burge wrote:
> On Tue, Jan 04, 2005 at 09:51:11AM -0800, Richard Henderson wrote:
> 
> > On Tue, Jan 04, 2005 at 10:14:03AM +0000, Nick Clifton wrote:
> > > Presumably yes.  But I assume that the feeling is that invoking an 
> > > assembler switch is simpler for the user than requiring them to write or 
> > > edit linker scripts.
> > 
> > If you're writing boot loaders, you're already writing linker scripts.
> 
> We currently don't use a linker script.  Here's the complete linker
> line:
> 
> alpha--netbsd-ld -Ttext 0x20000000 -N -e start -o bootxx_ffs.sym \
>   start.o bootxx.o booted_dev.o blkdev.o prom.o prom_disp.o putstr.o \
>   panic_putstr.o lib/sa/libsa.a kern/libkern.a -Map bootxx_ffs.map
> 
> Since we don't already use (and therefore have to maintain) a separate
> linker script, a command line option to not generate these new .eh_frame
> sections seems like the cleanest solution to me.

Hmm, doing
alpha--netbsd-ld -Ttext 0x20000000 -N --verbose 2>&1 \
  | sed -n '/^==========/,/^===========/{/^========/d;s,^[[:blank:]]*\.eh_frame[[:blank:]]*:,/DISCARD/ ,;p}' \
  > bootxx_ffs.lds
... -T bootxxxx_ffs.lds
doesn't seem to be much harder, does it?

	Jakub

Re: .eh_frame section on alpha

[Simon Burge]

On Tue, Jan 04, 2005 at 11:40:21PM +0100, Jakub Jelinek wrote:
> On Wed, Jan 05, 2005 at 08:27:20AM +1100, Simon Burge wrote:
> > On Tue, Jan 04, 2005 at 09:51:11AM -0800, Richard Henderson wrote:
> > 
> > > On Tue, Jan 04, 2005 at 10:14:03AM +0000, Nick Clifton wrote:
> > > > Presumably yes.  But I assume that the feeling is that invoking an 
> > > > assembler switch is simpler for the user than requiring them to write or 
> > > > edit linker scripts.
> > > 
> > > If you're writing boot loaders, you're already writing linker scripts.
> > 
> > We currently don't use a linker script.  Here's the complete linker
> > line:
> > 
> > alpha--netbsd-ld -Ttext 0x20000000 -N -e start -o bootxx_ffs.sym \
> >   start.o bootxx.o booted_dev.o blkdev.o prom.o prom_disp.o putstr.o \
> >   panic_putstr.o lib/sa/libsa.a kern/libkern.a -Map bootxx_ffs.map
> > 
> > Since we don't already use (and therefore have to maintain) a separate
> > linker script, a command line option to not generate these new .eh_frame
> > sections seems like the cleanest solution to me.
> 
> Hmm, doing
> alpha--netbsd-ld -Ttext 0x20000000 -N --verbose 2>&1 \
>   | sed -n '/^==========/,/^===========/{/^========/d;s,^[[:blank:]]*\.eh_frame[[:blank:]]*:,/DISCARD/ ,;p}' \
>   > bootxx_ffs.lds
> ... -T bootxxxx_ffs.lds
> doesn't seem to be much harder, does it?

This works, although I needed to change the "/DISCARD/ " to "/DISCARD/ : "
otherwise ld gave a "parse error".  I'll talk with the other NetBSD folks
that work in this area, but this looks good to me.

Back to part of my original question - why did the .eh_frame section
become mandatory on alpha when it doesn't appear to be on any other
architecture?  I'm not a C++ person, but I understood that this section
was used with the exception handling mechanism.

Thanks!
Simon.
--
Simon Burge                                   <simonb@wasabisystems.com>
NetBSD Development, Support and Service:   http://www.wasabisystems.com/

Re: .eh_frame section on alpha

[Richard Henderson]

On Wed, Jan 05, 2005 at 01:17:13PM +1100, Simon Burge wrote:
> Back to part of my original question - why did the .eh_frame section
> become mandatory on alpha when it doesn't appear to be on any other
> architecture?

Oh, but it does appear with other architectures.  x86-64, s390, and
ia64, at least.

> I'm not a C++ person, but I understood that this section was used
> with the exception handling mechanism.

Yes, but exceptions are the only reasonable way to implement POSIX
thread cancellation.  So we need to be able to handle exceptions
propagating through C and assembly code as well.

Alpha is (nearly) unique in that the original assembly language
specified directives from which unwind information can be derived.
Which meant that we don't have to go back and modify the assembly
specifically to add dwarf2 annotations to get things to work.


r~