This is the mail archive of the
mailing list for the GCC project.
More aggressive --gc-sections
- From: Eric Botcazou <ebotcazou at act-europe dot fr>
- To: binutils at sources dot redhat dot com,gcc at gcc dot gnu dot org
- Date: Wed, 10 Mar 2004 14:07:53 +0100
- Subject: More aggressive --gc-sections
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
- 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)
normal 35782030 8977976
--gc-sections 32460568 7696720
GPS (dynamically linked except GtkAda and AdaRTS)
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.