This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Test case which displays problem found in libstdc++-v3 effort


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]