Re: C and -fexceptions

[Jason Merrill <jason at cygnus dot com>]

>>>>> Jamie Lokier <egcs@tantalophile.demon.co.uk> writes:

 > That info is quite lengthy.  I'm thinking, that any function that has a
 > frame pointer and no destructors, could be represented by a single
 > eh_frame record, "unwind to frame pointer".  Furthermore, records for
 > several functions could be merged together if the functions are
 > adjacent.

The frame pointer isn't enough.  The info is necessary to tell the unwinder
where to find callee-saved registers and the caller's PC, not just the
caller's FP.  On the x86, it is also used to restore SP (popping args);
that's what takes most of the space.  However, that is only necessary for
frames with handlers; we could plausibly omit the args_size info for frames
that have no EH regions.

Actually, it isn't even really necessary for cleanups, since they'll just
run and rethrow, so it doesn't matter if we waste a bit of stack.  The only
case we need to worry about is repeatedly catching exceptions in the same
function without returning.

 > In the case of a C object compiled without -fomit-frame-pointer, that
 > would mean a single eh_frame record for the entire file.  It would no
 > longer add significant storage to have the -fexceptions flag set.

You can't quite do that; You still need 16 bytes per function for the
unwinder to look up the PC -- 4 bytes for the CIE pointer, 4 bytes for the
length of the FDE, 4 bytes for the start address, 4 bytes for the length.

There is room for improvement, though: The current redundancy in prologue
descriptions could be avoided by having the linker combine factor out
similar sequences into additional CIEs.

 > An alternative, is to consider any function that does not have an
 > eh_frame record as meaning "unwind to frame pointer".  But that wouldn't
 > be robust in the present of code compiled with -fomit-frame-pointer.

We definitely should implement some sort of default; we could use generic
unwinders like the ones in gdb if we don't find what we're looking for in
.eh_frame.  At that point, we start to look at time/space tradeoffs;
disassembling prologues isn't the speediest solution, and isn't an option
if we're pushing prologue code down into the function.  But it should work
just fine for the SPARC, say.

Jason