* .eh_frame section on alpha @ 2004-12-24 13:22 Simon Burge 2004-12-24 15:00 ` Ian Lance Taylor 0 siblings, 1 reply; 11+ messages in thread From: Simon Burge @ 2004-12-24 13:22 UTC (permalink / raw) To: binutils 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/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: .eh_frame section on alpha 2004-12-24 13:22 .eh_frame section on alpha Simon Burge @ 2004-12-24 15:00 ` Ian Lance Taylor 2004-12-29 7:39 ` Simon Burge 0 siblings, 1 reply; 11+ messages in thread From: Ian Lance Taylor @ 2004-12-24 15:00 UTC (permalink / raw) To: Simon Burge; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: .eh_frame section on alpha 2004-12-24 15:00 ` Ian Lance Taylor @ 2004-12-29 7:39 ` Simon Burge 2005-01-04 9:36 ` Nick Clifton 0 siblings, 1 reply; 11+ messages in thread From: Simon Burge @ 2004-12-29 7:39 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: binutils 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/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: .eh_frame section on alpha 2004-12-29 7:39 ` Simon Burge @ 2005-01-04 9:36 ` Nick Clifton 2005-01-04 9:58 ` Jakub Jelinek 0 siblings, 1 reply; 11+ messages in thread From: Nick Clifton @ 2005-01-04 9:36 UTC (permalink / raw) To: Simon Burge; +Cc: Ian Lance Taylor, binutils 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: .eh_frame section on alpha 2005-01-04 9:36 ` Nick Clifton @ 2005-01-04 9:58 ` Jakub Jelinek 2005-01-04 10:06 ` Nick Clifton 0 siblings, 1 reply; 11+ messages in thread From: Jakub Jelinek @ 2005-01-04 9:58 UTC (permalink / raw) To: Nick Clifton; +Cc: Simon Burge, Ian Lance Taylor, binutils 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: .eh_frame section on alpha 2005-01-04 9:58 ` Jakub Jelinek @ 2005-01-04 10:06 ` Nick Clifton 2005-01-04 17:51 ` Richard Henderson 0 siblings, 1 reply; 11+ messages in thread From: Nick Clifton @ 2005-01-04 10:06 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Simon Burge, Ian Lance Taylor, binutils 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: .eh_frame section on alpha 2005-01-04 10:06 ` Nick Clifton @ 2005-01-04 17:51 ` Richard Henderson 2005-01-04 21:27 ` Simon Burge 0 siblings, 1 reply; 11+ messages in thread From: Richard Henderson @ 2005-01-04 17:51 UTC (permalink / raw) To: Nick Clifton; +Cc: Jakub Jelinek, Simon Burge, Ian Lance Taylor, binutils 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~ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: .eh_frame section on alpha 2005-01-04 17:51 ` Richard Henderson @ 2005-01-04 21:27 ` Simon Burge 2005-01-04 22:40 ` Jakub Jelinek 0 siblings, 1 reply; 11+ messages in thread From: Simon Burge @ 2005-01-04 21:27 UTC (permalink / raw) To: Richard Henderson Cc: Nick Clifton, Jakub Jelinek, Simon Burge, Ian Lance Taylor, binutils 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/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: .eh_frame section on alpha 2005-01-04 21:27 ` Simon Burge @ 2005-01-04 22:40 ` Jakub Jelinek 2005-01-05 2:17 ` Simon Burge 0 siblings, 1 reply; 11+ messages in thread From: Jakub Jelinek @ 2005-01-04 22:40 UTC (permalink / raw) To: Simon Burge; +Cc: Richard Henderson, Nick Clifton, Ian Lance Taylor, binutils 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: .eh_frame section on alpha 2005-01-04 22:40 ` Jakub Jelinek @ 2005-01-05 2:17 ` Simon Burge 2005-01-05 3:14 ` Richard Henderson 0 siblings, 1 reply; 11+ messages in thread From: Simon Burge @ 2005-01-05 2:17 UTC (permalink / raw) To: Jakub Jelinek Cc: Simon Burge, Richard Henderson, Nick Clifton, Ian Lance Taylor, binutils 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/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: .eh_frame section on alpha 2005-01-05 2:17 ` Simon Burge @ 2005-01-05 3:14 ` Richard Henderson 0 siblings, 0 replies; 11+ messages in thread From: Richard Henderson @ 2005-01-05 3:14 UTC (permalink / raw) To: Simon Burge; +Cc: Jakub Jelinek, Nick Clifton, Ian Lance Taylor, binutils 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~ ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2005-01-05 3:14 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-12-24 13:22 .eh_frame section on alpha Simon Burge 2004-12-24 15:00 ` Ian Lance Taylor 2004-12-29 7:39 ` Simon Burge 2005-01-04 9:36 ` Nick Clifton 2005-01-04 9:58 ` Jakub Jelinek 2005-01-04 10:06 ` Nick Clifton 2005-01-04 17:51 ` Richard Henderson 2005-01-04 21:27 ` Simon Burge 2005-01-04 22:40 ` Jakub Jelinek 2005-01-05 2:17 ` Simon Burge 2005-01-05 3:14 ` Richard Henderson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).