This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: sjlj-exceptions ICE. simplified test case
- To: Geert Bosch <bosch at gnat dot com>
- Subject: Re: sjlj-exceptions ICE. simplified test case
- From: Michael Meissner <meissner at cygnus dot com>
- Date: Wed, 26 Apr 2000 18:53:11 -0400
- Cc: "law at cygnus dot com" <law at cygnus dot com>, Mark Mitchell <mark at codesourcery dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "robertl at sco dot com" <robertl at sco dot com>, "rth at cygnus dot com" <rth at cygnus dot com>
- References: <20000426183528.7790834D9D@nile.gnat.com>
On Wed, Apr 26, 2000 at 02:36:24PM -0400, Geert Bosch wrote:
> On Wed, 26 Apr 2000 08:18:37 -0600, Jeffrey A Law wrote:
>
> My experience has been that sjlj exceptions bloat things more than the
> tables do.
>
> This definately is not true for code with relatively few exception handlers,
> which is the case for most Ada programs used in embedded contexts.
>
> A common approach for exception handling is that handled regions only occur
> at the outer level of an application, where tasks are started and restarted
> if problems occur. The rest of the application has few, if any, handlers.
> It is clear that for such programs the setjump/long jump approach is the
> cheapest possible approach.
>
> For example, look at compiling cc1 (from gcc-2.95.2) with -O2 on x86 and
> stripping unneeded symbols. The resulting code is 2107580 bytes with
> unwind tables, and 1567012 without. So the tables require 34% space. On an
> embedded target where programs often need to be squeezed in available flash,
> space is at a premium and 30% is enough to make gcc unusable.
Note, you should use the size command to measure the size, and not do an ls,
since the object file wrapper does not matter for embedded programs.
On the other hand, I would assert that the x86 and 68k are both atypical due to
the fact that the unwind tables are much larger than they are machines that
define ACCUMULATE_OUTGOING_ARGS (ie, just about most other targets). It would
be interesting to see what the difference is on a Risc machine such as a SPARC,
Alpha, or PowerPC. This is because at every stack adjustment, a new entry into
the tables needs to be made. In addition, we could probably shrink the tables
by adding pseudo ops to the assembler, to allow it to emit the difference
between labels in compressed fashion, instead of doing it 4 bytes at a time
(the dwarf unwinder might need to be made a little smarter to deal with
alignment issues on some machines).
--
Michael Meissner, Cygnus Solutions, a Red Hat company.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: meissner@redhat.com phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org fax: +1 978-692-4482