This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
elf_gc_sections and relocatable sections
- From: Earl Chew <earl_chew at agilent dot com>
- To: binutils at sources dot redhat dot com
- Date: Wed, 08 Dec 2004 20:30:24 -0800
- Subject: elf_gc_sections and relocatable sections
I'm seeking some guidance here with binutils ld 2.15.91.0.2 and
why elf_gc_sections() disables garbage collection for relocateable
output.
I've previously been using binutils ld 2.10.1 in a VxWorks
environment where we build relocateable executables that can
be downloaded to a VxWorks target.
I posted:
http://sources.redhat.com/ml/binutils/2001-07/msg00260.html
and followed up with a private email exchange with
Richard Henderson.
I established that -gc-sections wasn't really incompatible
with -r, provided that there is one undefined symbol introduced
at the command line (-Umain) to establish a starting point for
the link. I made minor changes to 2.10.1 to enable --gc-sections
and -r on ELF and we've used this successfully for at least the
last two years.
Now at vesion 2.15.91.0.2 I see that things have changed since
2.10.1.
The code fragment at elf_gc_sections() is key to resurrecting my
patch with 2.15.91.0.2:
if (!get_elf_backend_data (abfd)->can_gc_sections
|| info->relocatable
|| info->emitrelocations
|| info->shared
|| !is_elf_hash_table (info->hash))
{
(*_bfd_error_handler)(_("Warning: gc-sections option ignored"));
return TRUE;
}
Can anyone shed any light as to why elf_gc_sections() cannot
proceed if info->relocatable or info->emitrelocations is set?
Is there something in the elf garbage collection algorithm or
implementation that causes it to fail under these circumstances?
ld already contains a guard to prevent -r and --gc-sections, so
in a sense this part of the guard in elf_gc_sections() duplicates
that check.
Earl