More aggressive --gc-sections

[Eric Botcazou <ebotcazou at act-europe dot fr>]

Hi,

ACT was asked by a customer to investigate (and possibly fix) why 
--gc-sections doesn't work for Ada programs, in conjunction with the 
compiler options -ffunction-sections -fdata-sections.  The answer is that 
the DWARF-2 EH mechanism glues all sections together.

So I've been experimenting with the following approach (for ELF):
- mark only the .eh_frame section instead of the whole graph rooted at the 
.eh_frame section; elf-eh-frame.c can then discard the FDEs for discarded 
functions,
- instruct GCC, when passed  -ffunction-sections, to split the 
.gcc_except_table section and emit an explicit back reference from the 
function section to the function-specific .gcc_except_table.func section,
- add the appropriate KEEPs to the linker script so that the EH machinery is 
not discarded (in particular, the section containing the EH personality 
routine is marked as KEEP).

This appears to work: unused functions are discarded from the final 
executable, even if the compiler generates FDEs and exception tables for 
them.  And the exceptions are correctly caught.

Moreover, I've also been experimenting with --gc-sections and dynamic 
linking, because I don't see any fundamental reason why other linkers can do 
it (see -Beliminate for Sun ld) and not the GNU linker. 


The scheme has only been tested on x86 Linux for the time being, both with 
GCC 3.5 and the development version of GNAT 5.  Here are some results with 
GNAT 5 (libgcc, AdaRTS, GtkAda, GPS compiled with -ff-s -fd-s):

GPS (fully dynamically linked)
                 debug    stripped
normal          35782030   8977976
--gc-sections   32460568   7696720

GPS (dynamically linked except GtkAda and AdaRTS)
                 debug     stripped
normal          37461737   10065784
--gc-sections   33471075    8419472

[GPS is the GNAT IDE written in Ada.]


We would like to have these features included in the official FSF trees (say 
GCC 3.5 and binutils 2.16).  The patches are relatively small for the time 
being but I'm fully aware that more work will probably be required in order 
to support other platforms.

What do you think about the approach?  What criteria should the patches meet 
to be accepted both in GCC and binutils?

Thanks in advance.

--
Eric Botcazou