increase in object code size

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

[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

[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

[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

[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

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

[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

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

code size/ linux -fno-strength-reduce

[Mark Phillips]

You might want to check the actual code size using size or objdump
--all-headers, maybe it is an increase in dbg size. Also check out other
peoples comments on exception handling.

The following will probably not help your code size, but may help
performance...

You may want to try dropping the -fno-strength-reduce, that option was
used to work round a long standing, major, bug in i386 code optimisation
present in gcc 2.7.2 and not fixed until 2.7.2.1 was finally released.

I have attached a test program if you want to check if egcs has the
problem....

Good Luck
Mark


Mark S. Phillips        ESN 742 2461
msp@nortel.co.uk        Tel. +44 1279 402461

On Tue, 23 Sep 1997, Thomas Koenig wrote:

> 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

[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: code size/ linux -fno-strength-reduce

[Horst von Brand]

Mark Phillips <M.S.Phillips@nortel.co.uk> said:
> On Tue, 23 Sep 1997, Thomas Koenig wrote:

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

> [Suggests deleting '-fno-strength-reduce', after checking that that bug
>  is gone]

Also add '-fno-exceptions', the bloat is from support for throwing
exceptions through C code (which most probably won't work right anyway, so
why bother is beyond me).
-- 
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