The problem with linkonce sections in ELF
Ian Lance Taylor
ian@zembu.com
Sun Feb 6 13:20:00 GMT 2000
Date: Thu, 3 Feb 2000 20:45:49 -0800
From: "H . J . Lu" <hjl@lucon.org>
The probelm is the output .rel.text section consists of .rel.text,
.rel.text.* and .rel.gnu.linkonce.t*. All the them are generated
by the linker. With -Bsymbolic, elf_i386_size_dynamic_sections calls
if (info->shared && info->symbolic)
elf_i386_link_hash_traverse (elf_i386_hash_table (info),
elf_i386_discard_copies,
(PTR) NULL);
It is very possible that one of the .rel.gnu.linkonce.t* relocations
created by the linker will be striped by _bfd_strip_section_from_output.
When it happens, the output .rel.text section will be removed although
there are other .rel.text, .rel.text.* and .rel.gnu.linkonce.t* left.
I think _bfd_strip_section_from_output has to be 100% sure that
all linker generated relocations are striped before it removes
the output relocation section.
Thanks for the analysis and the test case.
I don't know why _bfd_strip_section_from_output looks at link_order
information at all. In all the calls that I can see, the link_order
information has not yet been set up. Now I see why you were trying to
add link_order information earlier.
But that doesn't make sense. The link_order information is only
meaningful after section sizes are known. Section sizes are not known
when size_dynamic_section is called, and size_dynamic_section
generates all the current calls to strip_section_from_output.
The appended patch fixes the problem for me. You also have to
regenerate bfd-in2.h, and patch all the calls to size_dynamic_sections
to pass the extra argument. This is not very efficient; I don't know
how often strip_section_from_output is called in real cases.
Ian
Index: section.c
===================================================================
RCS file: /cvs/binutils/binutils/bfd/section.c,v
retrieving revision 1.10
diff -u -r1.10 section.c
--- section.c 2000/01/13 22:10:36 1.10
+++ section.c 2000/02/06 21:14:48
@@ -1100,20 +1100,28 @@
SYNOPSIS
void _bfd_strip_section_from_output
- (asection *section);
+ (struct bfd_link_info *info, asection *section);
DESCRIPTION
- Remove @var{section} from the output. If the output section becomes
- empty, remove it from the output bfd.
+ Remove @var{section} from the output. If the output section
+ becomes empty, remove it from the output bfd. @var{info} may
+ be NULL; if it is not, it is used to decide whether the output
+ section is empty.
*/
void
-_bfd_strip_section_from_output (s)
+_bfd_strip_section_from_output (info, s)
+ struct bfd_link_info *info;
asection *s;
{
asection **spp, *os;
struct bfd_link_order *p, *pp;
+ boolean keep_os;
- /* Excise the input section from the link order. */
+ /* Excise the input section from the link order.
+
+ FIXME: For all calls that I can see to this function, the link
+ orders have not yet been set up. So why are we checking them? --
+ Ian */
os = s->output_section;
for (p = os->link_order_head, pp = NULL; p != NULL; pp = p, p = p->next)
if (p->type == bfd_indirect_link_order
@@ -1128,10 +1136,30 @@
break;
}
+ keep_os = os->link_order_head != NULL;
+
+ if (! keep_os && info != NULL)
+ {
+ bfd *abfd;
+ for (abfd = info->input_bfds; abfd != NULL; abfd = abfd->link_next)
+ {
+ asection *is;
+ for (is = abfd->sections; is != NULL; is = is->next)
+ {
+ if (is->output_section == os)
+ break;
+ }
+ if (is != NULL)
+ break;
+ }
+ if (abfd != NULL)
+ keep_os = true;
+ }
+
/* If the output section is empty, remove it too. Careful about sections
that have been discarded in the link script -- they are mapped to
bfd_abs_section, which has no owner. */
- if (!os->link_order_head && os->owner)
+ if (!keep_os && os->owner != NULL)
{
for (spp = &os->owner->sections; *spp; spp = &(*spp)->next)
if (*spp == os)
More information about the Binutils
mailing list