This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: Test case which displays problem found in libstdc++-v3 effort
- To: Jason Merrill <jason at cygnus dot com>
- Subject: Re: Test case which displays problem found in libstdc++-v3 effort
- From: Alan Modra <alan at linuxcare dot com dot au>
- Date: Sat, 24 Jun 2000 00:40:21 +1000 (EST)
- cc: Benjamin Kosnik <bkoz at redhat dot com>, binutils at sourceware dot cygnus dot com, libstdc++ at sourceware dot cygnus dot com
I'm learning some things about linker garbage collection. :) The first
thing to note is that garbage collection is done on linker input sections,
not on output sections. What this means is that there must be a reference
to symbols defined in *each* input section (or a KEEP statement in the
linker script) to ensure that the section is output.
As an example, suppose we have 4 simple source files
t1.s
====
.text
.global _start
.extern foo
_start: jmp foo
t2.s
====
.text
.global foo
foo: nop
t3.s
====
.text
.global bar
.extern zzz
bar: jmp zzz
t4.s
====
.text
.global zzz
.extern bar
zzz: jmp bar
Assembling and linking these files with --gc-sections will produce an
output with no trace of the t3 or t4 .text section. t1 .text is kept
because _start is special, t2 .text is kept because of the reference in a
section we decided to keep, t1. But there's no reference in any of the
kept sections to t3 .text or t4 .text, so these are dropped.
What this all means is that .eh_frame definitely needs to be marked KEEP
in the linker script (and my comment about a linker bug is wrong). You
won't get all .eh_frame input sections in the output just because there is
a reference to one of them.
Regards, Alan Modra
--
Linuxcare. Support for the Revolution.