Re: increase in object code size

Re: increase in object code size

[Mike Stump]

> From: Joe Buck <jbuck@synopsys.com>
> To: mrs@wrs.com (Mike Stump)
> Date: Tue, 23 Sep 97 21:28:54 PDT

> > There is already code (can_throw (insn)) in there that know that can
> > throw and what can't.  If people use it, then both camps come out
> > winning.

> I don't understand.  How will this permit safe throws from async signals?

Let me start off by saying that it isn't safe.  I think we all know
this.  The language standard doesn't permit code to rely upon it.
There is a reason why that it.  On some platforms, even though it
appears to work, sometimes it won't, so in yet another sense it isn't
safe.

It may be necessary on some platforms to extend the compiler out to
deal properly with dummy signal frames and the like for much of
anything to work.  On some platforms this isn't necessary.  The fact
remains that some people do want this, and are doing it today.  They
aren't looking for guarantees, what they are looking for for a way out
when they have already lost, a last chance at surviving.

Re: increase in object code size

[Mike Stump]

> From: Richard Henderson <rth@cygnus.com>
> To: jfc@mit.edu (John Carr)
> Date: Tue, 23 Sep 1997 17:01:54 -0700 (PDT)

> > The first optimization which comes to mind: an exception table entry
> > which does not apply to an instruction which can throw an exception
> > should be eliminated.  In GNU C and C++ (and, I think, GNU Ada) only
> > function calls throw exceptions.  That means there needs to be at most
> > one table entry per function call.

> No, because you will want to support throwing exceptions from 
> signal handlers.  This is most useful from synchronous signals
> such as SEGV and FPE, but I could also see uses for ALRM.

There is already code (can_throw (insn)) in there that know that can
throw and what can't.  If people use it, then both camps come out
winning.

Re: increase in object code size

[Joe Buck]

> There is already code (can_throw (insn)) in there that know that can
> throw and what can't.  If people use it, then both camps come out
> winning.

I don't understand.  How will this permit safe throws from async signals?

Re: increase in object code size

[Jason Merrill]

>>>>> Horst von Brand <vonbrand@inf.utfsm.cl> writes:

> Jason Merrill <jason@cygnus.com> said:
>> This bloat can be significantly reduced by potential optimizations in the
>> assembler.  [...]

> Nice idea for C++/Ada!

> And how do we get rid of it completely for the portable assembler, aka C?

With this mechanism, we can't eliminate it and still support throwing
through C code.  Without the unwind info, the EH runtime doesn't know how
to unwind stack frames.  The setjmp/longjmp code avoids this problem by
recording the necessary state, which significantly slows down C++ code that
doesn't throw.

SGI also uses the dwarf2 info, but reads it out of the executable as
needed.  OSF/1 uses static data generated by the assembler, which I assume
is smaller and less general than the dwarf2 info; Richard tells me it
requires the prologue to be a precise sequence of instructions.

It's a difficult tradeoff.

Jason

Re: increase in object code size

[Horst von Brand]

Jason Merrill <jason@cygnus.com> said:
> >>>>> Horst von Brand <vonbrand@inf.utfsm.cl> writes:
> > Jason Merrill <jason@cygnus.com> said:
> >> This bloat can be significantly reduced by potential optimizations in the
> >> assembler.  [...]

> > Nice idea for C++/Ada!

> > And how do we get rid of it completely for the portable assembler, aka C?

> With this mechanism, we can't eliminate it and still support throwing
> through C code.  Without the unwind info, the EH runtime doesn't know how
> to unwind stack frames.  The setjmp/longjmp code avoids this problem by
> recording the necessary state, which significantly slows down C++ code that
> doesn't throw.

Who wants to throw through C can compile with g++ (or use some special
-fmagic-exception-handling-for-throwing-though-this), the bloat in C is
totally unwarranted, and gives nothing useful in return.

A quick check (I'll look at that closer tonight) makes gcc-2.90.09 generate
a xgcc that is fully 40% larger (!) than the one built by gcc-2.90.06.
Both for the same sources (egcs-970922 + patches posted here for compiling
to work on i586-pc-linuxlibc1), CFLAGS='-O2 -fomit-frame-pointer -mpentium'
-- 
Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: increase in object code size

[Thomas Koenig]

Warner Losh wrote:
>In message < 199709231418.QAA27370@mvmap66.ciw.uni-karlsruhe.de > Thomas Koenig writes:
>: Any idea what's causing this?  Are the options wrong?
>
>What does size say for these modules?

egcs, with -fno-exceptions:

$ size 3c59x.o
text    data    bss     dec     hex     filename
14367   264     0       14631   3927    3c59x.o
$ ls -l 3c59x.o
-rw-r--r--   1 root     root        20260 Sep 23 18:40 3c59x.o

$ size ipv4.o
text    data    bss     dec     hex     filename
89979   3680    192     93851   16e9b   ipv4.o
$ ls -l ipv4.o
-rw-r--r--   1 root     root       128099 Sep 23 18:49 ipv4.o

egcs, without -fno-exceptions:

$ size 3c59x.o
text    data    bss     dec     hex     filename
14367   5836    0       20203   4eeb    3c59x.o
$ ls -l 3c59x.o
-rw-r--r--   1 root     root        26308 Sep 23 18:53 3c59x.o

$ size ipv4.o
text    data    bss     dec     hex     filename
89979   50308   192     140479  224bf   ipv4.o
$ ls -l ipv4.o
-rw-r--r--   1 root     root       179663 Sep 23 18:55 ipv4.o

gcc 2.7.2.1:

$ size 3c59x.o
text    data    bss     dec     hex     filename
14460   264     0       14724   3984    3c59x.o
$ ls -l 3c59x.o
-rw-r--r--   1 root     root        20344 Sep 23 18:57 3c59x.o

$ size ipv4.o
text    data    bss     dec     hex     filename
89503   3680    192     93375   16cbf   ipv4.o
$ ls -l ipv4.o
-rw-r--r--   1 root     root       126775 Sep 23 18:58 ipv4.o

So... looks like the data section being stuffed by exception handling.
Is there any reason to keep this for C?
-- 
Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, ig25@dkauni2.bitnet.
The joy of engineering is to find a straight line on a double
logarithmic diagram.

increase in object code size

[Thomas Koenig]

I recently compiled the 2.0.31-pre10 Linux i386 kernel egcs 970917, and
I noted an increase in object code size against compliation with gcc
2.7.2.1

For example, ~linux/drivers/net/3c59x.o grew from 20344 to 26308 bytes,
and ~linux/net/ipv4.o from 126775 to 179663 bytes.  Compile options were
standard for Linux, i.e. "-O2 -fomit-frame-pointer -fno-strength-reduce
-pipe -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2".

Any idea what's causing this?  Are the options wrong?
-- 
Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, ig25@dkauni2.bitnet.
The joy of engineering is to find a straight line on a double
logarithmic diagram.

Re: increase in object code size

[Joe Buck]

> I recently compiled the 2.0.31-pre10 Linux i386 kernel egcs 970917, and
> I noted an increase in object code size against compliation with gcc
> 2.7.2.1

You might check to see whether -fno-exceptions has an effect.  There
is some overhead to support propagating exceptions through, even in C
(at least with some of the three distinct exceptions implementations,
I think there isn't any for the setjmp/longjmp version).

Re: increase in object code size

[John Carr]

> You might check to see whether -fno-exceptions has an effect.

On 80386, -fno-exceptions reduces size by about 25%.  "size -f" on
SVR4 and similar systems will show the size by section; you should see
an exception section (.eh_frame) about 30% as large as the code
section.  This is present even in C code which doesn't use exceptions.

Re: increase in object code size

[Joe Buck]

> > You might check to see whether -fno-exceptions has an effect.
> 
> On 80386, -fno-exceptions reduces size by about 25%.  "size -f" on
> SVR4 and similar systems will show the size by section; you should see
> an exception section (.eh_frame) about 30% as large as the code
> section.  This is present even in C code which doesn't use exceptions.

This kind of bloat in C code isn't going to be acceptable for a feature
that is rarely needed (being able to throw exceptions through C code).

At the risk of re-starting a big fight that appeared on the gcc2 list
a while back:

Perhaps -fno-exceptions should be the default for C, while -fexceptions
should be the default for C++.  Folks who need to use exceptions in a
mixed environment can use -fexceptions for C.  C Library functions that
take pointers to functions (qsort) should be compiled with -fexceptions.

Re: increase in object code size

[Jason Merrill]

>>>>> Joe Buck <jbuck@synopsys.com> writes:

>> > You might check to see whether -fno-exceptions has an effect.
>> 
>> On 80386, -fno-exceptions reduces size by about 25%.  "size -f" on
>> SVR4 and similar systems will show the size by section; you should see
>> an exception section (.eh_frame) about 30% as large as the code
>> section.  This is present even in C code which doesn't use exceptions.

This bloat can be significantly reduced by potential optimizations in the
assembler.  Currently, adjusting the effective PC takes 5 bytes.  This can
be reduced to 1 byte in most cases, but the compiler makes pessimistic
assumptions because it doesn't know the size of instructions.

The assembler and linker can also do a lot of commonization; most function
prologues look the same, so repeated sequences can be factored out into the
CIE, and identical CIEs can be shared between translation units.  This
would leave an overhead of 16 bytes per function.

This just needs someone to do the BFD work.

Jason

Re: increase in object code size

[Joe Buck]

> On 80386, -fno-exceptions reduces size by about 25%.  "size -f" on
> SVR4 and similar systems will show the size by section; you should see
> an exception section (.eh_frame) about 30% as large as the code
> section.  This is present even in C code which doesn't use exceptions.

That much?  On sparc-sun-solaris2.5.1, size -A on a stripped cc1 from the
latest snapshot gives

section         size         addr
.interp           17        65748
.hash          19840        65768
.dynsym        39280        85608
.dynstr        40912       124888
.rela.got         12       165800
.rela.bss         36       165812
.rela.plt        612       165848
.text        1537124       166460
.init             28      1703584
.fini             20      1703612
.rodata       188754      1703632
.got              32      1957924
.dynamic         136      1957956
.plt             664      1958092
.data          21620      1958760
.ctors             8      1980380
.dtors             8      1980388
.eh_frame      72120      1980396
.bss           85524      2052520
.comment        6616            0
Total        2013363

.eh_frame is only 4.7% of .text here.  Is the bloat that much larger
for x86?  Why?

Another factor that may make some bloat more acceptable is if the
.eh_frame section is read only when exceptions are being thrown,
it never gets paged in when there aren't any exceptions (meaning
that the penalty is disk-only).

Re: increase in object code size

[Thomas Koenig]

Joe Buck wrote:

>Another factor that may make some bloat more acceptable is if the
>.eh_frame section is read only when exceptions are being thrown,
>it never gets paged in when there aren't any exceptions (meaning
>that the penalty is disk-only).

Not when the binary in question is the Linux kernel.  In that case, it gets
stuck in real memory permanently...
-- 
Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, ig25@dkauni2.bitnet.
The joy of engineering is to find a straight line on a double
logarithmic diagram.

Re: increase in object code size

[Jakub Jelinek]

> 
> Joe Buck wrote:
> 
> >Another factor that may make some bloat more acceptable is if the
> >.eh_frame section is read only when exceptions are being thrown,
> >it never gets paged in when there aren't any exceptions (meaning
> >that the penalty is disk-only).
> 
> Not when the binary in question is the Linux kernel.  In that case, it gets
> stuck in real memory permanently...

Oh yes, but that's just one single program. And we can easily put
-fno-exceptions into CFLAGS when building it.

Cheers,
    Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
Ultralinux - first 64bit OS to take full power of the UltraSparc
Linux version 2.1.56 on a sparc machine (333.41 BogoMips).
___________________________________________________________________

Re: increase in object code size

[Jason Merrill]

>>>>> Joe Buck <jbuck@synopsys.com> writes:

> .eh_frame is only 4.7% of .text here.  Is the bloat that much larger
> for x86?  Why?

Yes, because on the x86 (and other PUSH_ROUNDING targets) you need to track
the size of of the args on the stack so you can pop them properly (and if
you used -fomit-frame-pointer, you need to track the changing CFA offset).
RISC targets define ACCUMULATE_OUTGOING_ARGS, so space for call args is
allocated in the prologue.

>>>>> Thomas Koenig <ig25@mvmap66.ciw.uni-karlsruhe.de> writes:

> Joe Buck wrote:
>> Another factor that may make some bloat more acceptable is if the
>> .eh_frame section is read only when exceptions are being thrown,
>> it never gets paged in when there aren't any exceptions (meaning
>> that the penalty is disk-only).

> Not when the binary in question is the Linux kernel.  In that case, it gets
> stuck in real memory permanently...

So compile the kernel with -fno-exceptions.

Jason

Re: increase in object code size

[Torbjorn Lindgren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1088 bytes --]

On 23 Sep 1997, Jason Merrill wrote:
> > Not when the binary in question is the Linux kernel.  In that case, it gets
> > stuck in real memory permanently...
> 
> So compile the kernel with -fno-exceptions.

It's C code, and as discussed on comp.lang.c++.moderated throwing
exceptions through C code is usually an extremely bad idea even if does
work on some compilers (you usually get at least resource leaks, and
outright breakage due to inconsistencies may well happen).

Note that this isn't something the compiler can fix, which is why I would
strongly propagate making -fno-exceptions DEFAULT for C code.

If someone really create C code which is exception-safe (it works if
correctly if one of the C++ functions under it throws an exception,
without resource leaks or garbled state information) and really want to
throw exceptions through their *C* code they should use -fexceptions
IMNSHO.


Ref: comp.lang.c++.moderated: 'Exceptions "through" non C++ functions'


-- 
Torbjörn Lindgren
E-mail: tl@funcom.com
If Santa ever DID deliver presents on Christmas Eve, he's dead now.

Re: increase in object code size

[John Carr]

> > On 80386, -fno-exceptions reduces size by about 25%.
> 
> That much?  On sparc-sun-solaris2.5.1, size -A on a stripped cc1 from the
> latest snapshot gives
> 
> section         size         addr
> .text        1537124       166460
> .eh_frame      72120      1980396
> 
> .eh_frame is only 4.7% of .text here.  Is the bloat that much larger
> for x86?  Why?

On x86 every stack push requires a 7 byte entry in the traceback table
so the unwinder knows how to adjust the stack pointer to find the
return address.

The first optimization which comes to mind: an exception table entry
which does not apply to an instruction which can throw an exception
should be eliminated.  In GNU C and C++ (and, I think, GNU Ada) only
function calls throw exceptions.  That means there needs to be at most
one table entry per function call.

The second (x86 only): if a function does not have any exception
handlers and it has a frame pointer the unwinder does not need an
exception table.  The return PC is at a known offset from the frame
pointer.

("exception handler" here includes implicitly defined handlers in C++
to call destructors for local variables.)

Re: increase in object code size

[Richard Henderson]

> The first optimization which comes to mind: an exception table entry
> which does not apply to an instruction which can throw an exception
> should be eliminated.  In GNU C and C++ (and, I think, GNU Ada) only
> function calls throw exceptions.  That means there needs to be at most
> one table entry per function call.

No, because you will want to support throwing exceptions from 
signal handlers.  This is most useful from synchronous signals
such as SEGV and FPE, but I could also see uses for ALRM.


r~

Re: increase in object code size

[Joe Buck]

> > The first optimization which comes to mind: an exception table entry
> > which does not apply to an instruction which can throw an exception
> > should be eliminated.  In GNU C and C++ (and, I think, GNU Ada) only
> > function calls throw exceptions.  That means there needs to be at most
> > one table entry per function call.
> 
> No, because you will want to support throwing exceptions from 
> signal handlers.  This is most useful from synchronous signals
> such as SEGV and FPE, but I could also see uses for ALRM.

Forget it.  You can't support throwing asynchronous exceptions from signal
handlers.  If you attempt to, you can't write reliable code.  (You may
be able to support SEGV and FPE if you can always clean up the stack,
but I wouldn't advise it).

Consider this:

	char* p = 0;
	try {
		p = malloc(100);
	}
	catch (...) {
		if (p != 0)
			free(p);
	}

Question: is this correct if the ALRM handler throws an exception?  Can we
guarantee no memory leaks or frees of unallocated memory?

Answer: no; not even if we put locks inside malloc, since there isn't
a way to put a lock between the return of malloc and the assign of p.
You'll never debug failures coming from this.

Re: increase in object code size

[Joern Rennecke]

> > The first optimization which comes to mind: an exception table entry
> > which does not apply to an instruction which can throw an exception
> > should be eliminated.  In GNU C and C++ (and, I think, GNU Ada) only
> > function calls throw exceptions.  That means there needs to be at most
> > one table entry per function call.
> 
> No, because you will want to support throwing exceptions from 
> signal handlers.  This is most useful from synchronous signals
> such as SEGV and FPE, but I could also see uses for ALRM.

How about this: make a not too bulky algorithm that can keep track of
the stack pointer through most code. from the start of the function
or from an extra recorded help point.  Then the compiler, assembler or
linker checks at compile/link time if this algorithm works for the emitted
code.  If it fails somewhere, or it would become too costly to walk
through a long sequence of instructions, an extra help point is inserted
where the stack use is recorded.  I think this should allow to save most
of the extra EH information but still allow precision.

Re: increase in object code size

[Jason Merrill]

>>>>> Richard Henderson <rth@cygnus.com> writes:

> No, because you will want to support throwing exceptions from 
> signal handlers.  This is most useful from synchronous signals
> such as SEGV and FPE, but I could also see uses for ALRM.

Not gon' happen, or not everywhere anyway.  On the x86, SEGV screws up the
stack.  How do you unwind a signal handler?

Jason

Re: increase in object code size

[Richard Henderson]

> Not gon' happen, or not everywhere anyway.  On the x86, SEGV screws up the
> stack.  How do you unwind a signal handler?

On OSF/1 they do it by making the process context used by the
exception code the same as struct sigcontext that is passed into
the signal handler.  Thus you do

  int sighandler(int sig, siginfo_t *info, void *_c)
  {
    ucontext_t *context = (ucontext_t *)_c;
    exc_raise_signal_exception(myexcptnr, mycode, &context->uc_mcontext);
  }

So you actually start the unwind in the context the signal happened 
in.  It is pretty spiff, really.  I'm of the opinion that we should
open up the internals of our exception handling in similar ways.

As for the lossage with try malloc catch free, well those are the
breaks.  But there are other ways to use signals and exceptions that
are useful.  Admittedly SEGV ans FPE are the best examples...


r~

Re: increase in object code size

[Jason Merrill]

>>>>> Richard Henderson <rth@cygnus.com> writes:

> On OSF/1 they do it by making the process context used by the
> exception code the same as struct sigcontext that is passed into
> the signal handler.

Hmm, interesting.  Unfortunately, sigcontext is not universal.  In
particular, Linux doesn't seem to have it.  That could be fixed, of
course...

Jason

Re: increase in object code size

[David S. Miller]

   From: Jason Merrill <jason@cygnus.com>
   Date: 23 Sep 1997 22:46:30 -0700

   Hmm, interesting.  Unfortunately, sigcontext is not universal.  In
   particular, Linux doesn't seem to have it.  That could be fixed, of
   course...

On sparc64-linux it does.

Later,
David "Sparc" Miller
davem@caip.rutgers.edu

Re: increase in object code size

[Richard Henderson]

> Hmm, interesting.  Unfortunately, sigcontext is not universal.

Perhaps not, but it is available on all of the modern unices.

> In particular, Linux doesn't seem to have it.  That could be fixed, of
> course...

Sure it does; see <asm/sigcontext.h>.  Though a the moment it
varies how to get hold of it on the signal stack.  On i386-linux
you get it with a function definition of

  void handler(int sig, struct sigcontext context)

Note that the struct is passed by value.  On the riscy linuxes,
we take a more svr4 approach of passing the address in the third
argument.

Anyway, That will be fixed once my posix.1b signal stuff is merged,
since that standard defines all three arguments, rather than just
one that posix.1 1990 gave us.


r~

Re: increase in object code size

[Jason Merrill]

>>>>> John Carr <jfc@mit.edu> writes:

> The first optimization which comes to mind: an exception table entry
> which does not apply to an instruction which can throw an exception
> should be eliminated.  In GNU C and C++ (and, I think, GNU Ada) only
> function calls throw exceptions.  That means there needs to be at most
> one table entry per function call.

True.  In general, the current output is precise at the cost of size.  It
could be shrunk at the cost of precision.  This is one case.  Another would
be pretending that all the prologue stuff happened at the PC after the
prologue, so you only need one advance PC instruction.

> The second (x86 only): if a function does not have any exception
> handlers and it has a frame pointer the unwinder does not need an
> exception table.  The return PC is at a known offset from the frame
> pointer.

But how do you restore the saved registers?  That's what the unwind info is
for.

Jason