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

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

[Loren James Rittle]

Alan,

> It's a linker script bug.  The linker needs to be told to keep the
> .eh_frame contents.  Lack of any reference to symbols defined in a
> section normally causes --gc-sections to discard the section.

Thanks!  I can confirm that your patch fixes the test case when used
with mainline CVS gcc.

Regarding the NEWS file update, I can also confirm that section GC
appears to be working fine on my i386-elf platform.

Regards,
Loren

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

[Richard Henderson]

On Sat, Jun 24, 2000 at 12:40:21AM +1000, Alan Modra wrote:
> 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.

Yep.  Note that there is a new section group extension being
considered in the ELF committee meetings.  What that means is
that a set of input sections must be kept or scraped together.

I believe this was originally intended for debugging info, but
it would be equally relevant here -- keep the .eh_frame iff we
keep the .text that went with it.


r~

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

[Jason Merrill]

>>>>> Alan Modra <alan@linuxcare.com.au> writes:

 > 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.

This makes sense.  Thanks!

Jason

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

[Alan Modra]

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.

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

[Alan Modra]

On 22 Jun 2000, Jason Merrill wrote:

> >>>>> Alan Modra <alan@linuxcare.com.au> writes:
> 
>  > On 19 Jun 2000, Jason Merrill wrote:
>  >> >>>>> Alan Modra <alan@linuxcare.com.au> writes:
>  >> 
>  >>  > It's a linker script bug.  The linker needs to be told to keep the
>  >>  > .eh_frame contents.  Lack of any reference to symbols defined in a
>  >>  > section normally causes --gc-sections to discard the section.
>  >> 
>  >> I would think that the reference to __EH_FRAME_BEGIN__ from
>  >> __do_global_ctors would satisfy the linker.  Why doesn't it?
> 
>  > Because there doesn't seem to be any such reference.  __main.o doesn't
>  > have much in it on i586-linux.
> 
> What about crt{begin,end}.o?

Yep, there's a reference to __EH_FRAME_BEGIN__ in crtbegin.o.  Sooo, this
makes it a linker bug after all, and my patch to the script is just
papering over the problem.  Hmm, looking at objdump output, we actually
get a reference to the section symbol:

  35:   68 00 00 00 00          push   $0x0
                        36: R_386_32    .eh_frame
  3a:   e8 fc ff ff ff          call   3b <__do_global_dtors_aux+0x3b>

That ought to be enough to ensure the .eh_frame section gets kept, but I'm
guessing that section symbols aren't looked at for some reason.  I'll see
if I can fix this later on today if I find some time.

Here's a very simple set of test files if someone else wants to look at
this problem

cat > t1.s <<EOF
 .text
 .global _start
_start:
 mov __EH_FRAME_BEGIN__, %eax
 jmp _start

 .section .keepme,"aw"
 .type __EH_FRAME_BEGIN__,@object
__EH_FRAME_BEGIN__:
EOF
cat > t2.s <<EOF
 .section .keepme,"aw"
 .long 0
EOF
as -o t1.o t1.s
as -o t2.o t2.s
ld -static --gc-sections t1.o t2.o
objdump --headers a.out

a.out:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0000000a  08048074  08048074  00000074  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .sbss         00000000  0804907e  0804907e  0000007e  2**0
                  CONTENTS
  2 .bss          00000002  0804907e  0804907e  0000007e  2**0
                  CONTENTS
  3 .keepme       00000000  0804907e  0804907e  0000007e  2**0
                  CONTENTS, ALLOC, LOAD, DATA

And .keepme should be 4 bytes long.

Regards, Alan Modra
-- 
Linuxcare.  Support for the Revolution.

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

[Jason Merrill]

>>>>> Alan Modra <alan@linuxcare.com.au> writes:

 > On 19 Jun 2000, Jason Merrill wrote:
 >> >>>>> Alan Modra <alan@linuxcare.com.au> writes:
 >> 
 >>  > It's a linker script bug.  The linker needs to be told to keep the
 >>  > .eh_frame contents.  Lack of any reference to symbols defined in a
 >>  > section normally causes --gc-sections to discard the section.
 >> 
 >> I would think that the reference to __EH_FRAME_BEGIN__ from
 >> __do_global_ctors would satisfy the linker.  Why doesn't it?

 > Because there doesn't seem to be any such reference.  __main.o doesn't
 > have much in it on i586-linux.

What about crt{begin,end}.o?

Jason

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

[Alan Modra]

On 19 Jun 2000, Jason Merrill wrote:

> >>>>> Alan Modra <alan@linuxcare.com.au> writes:
> 
>  > It's a linker script bug.  The linker needs to be told to keep the
>  > .eh_frame contents.  Lack of any reference to symbols defined in a
>  > section normally causes --gc-sections to discard the section.
> 
> I would think that the reference to __EH_FRAME_BEGIN__ from
> __do_global_ctors would satisfy the linker.  Why doesn't it?

Because there doesn't seem to be any such reference.  __main.o doesn't
have much in it on i586-linux.  Everything is #ifdef'd out due to
HAS_INIT_SECTION and OBJECT_FORMAT_ELF being defined.

objdump --headers __main.o 

__main.o:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000000  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         00000000  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000000  00000000  00000000  00000034  2**2
                  ALLOC
  3 .note         00000014  00000000  00000000  00000034  2**0
                  CONTENTS, READONLY
  4 .stab         00000ee8  00000000  00000000  00000048  2**2
                  CONTENTS, RELOC, READONLY, DEBUGGING
  5 .stabstr      00002f51  00000000  00000000  00000f30  2**0
                  CONTENTS, READONLY, DEBUGGING
  6 .comment      00000029  00000000  00000000  00003e81  2**0
                  CONTENTS, READONLY


-- 
Linuxcare.  Support for the Revolution.

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

[Jason Merrill]

>>>>> Alan Modra <alan@linuxcare.com.au> writes:

 > It's a linker script bug.  The linker needs to be told to keep the
 > .eh_frame contents.  Lack of any reference to symbols defined in a
 > section normally causes --gc-sections to discard the section.

I would think that the reference to __EH_FRAME_BEGIN__ from
__do_global_ctors would satisfy the linker.  Why doesn't it?

Jason

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

[Benjamin Kosnik]

Great! This works. Can you please check it in? Thanks again,

Benjamin

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

[Alan Modra]

On Sun, 18 Jun 2000, Benjamin Kosnik wrote:

> More info on this bug can be found on the libstdc++ list, here:
> 
> http://sourceware.cygnus.com/ml/libstdc++/2000-06/msg00127.html
> http://sourceware.cygnus.com/ml/libstdc++/2000-06/msg00128.html
> 
> in which jason says:
> 
> 
> Or in a relatively mundane way; as it happens, it's simply discarding all
> of the unwind info.  objdump -x a.out shows that the .eh_frame section is
> size 0, which would seem to indicate a problem...
> 
> Definitely seems like a linker bug.

It's a linker script bug.  The linker needs to be told to keep the
.eh_frame contents.  Lack of any reference to symbols defined in a
section normally causes --gc-sections to discard the section.

The following patch should fix this problem.

Alan Modra
-- 
Linuxcare.  Support for the Revolution.


ld/ChangeLog

	* scripttempl/elf.sc: KEEP .eh_frame contents.


Index: ld/scripttempl/elf.sc
===================================================================
RCS file: /cvs/src/src/ld/scripttempl/elf.sc,v
retrieving revision 1.11
diff -u -p -r1.11 elf.sc
--- elf.sc	2000/04/13 23:38:46	1.11
+++ elf.sc	2000/06/18 11:32:27
@@ -244,7 +244,7 @@ SECTIONS
     ${CONSTRUCTING+SORT(CONSTRUCTORS)}
   }
   .data1 ${RELOCATING-0} : { *(.data1) }
-  .eh_frame : { *(.eh_frame) }
+  .eh_frame : { KEEP (*(.eh_frame)) }
   .gcc_except_table : { *(.gcc_except_table) }
   ${WRITABLE_RODATA+${RODATA}}
   ${RELOCATING+${OTHER_READWRITE_SECTIONS}}

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

[Benjamin Kosnik]

More info on this bug can be found on the libstdc++ list, here:

http://sourceware.cygnus.com/ml/libstdc++/2000-06/msg00127.html
http://sourceware.cygnus.com/ml/libstdc++/2000-06/msg00128.html

in which jason says:


Or in a relatively mundane way; as it happens, it's simply discarding all
of the unwind info.  objdump -x a.out shows that the .eh_frame section is
size 0, which would seem to indicate a problem...

Definitely seems like a linker bug.


Can somebody with linker expertise please look at this?

thanks,
benjamin

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

[Loren James Rittle]

There is talk of using -ffunction-sections -fdata-sections (to compile
the libstdc++-v3 library code) and to suggest -Wl,--gc-sections (for
any static links against the library) on any platforms which supports
those options.  On those platforms, the test suite for libstdc++-v3
would always add -Wl,--gc-sections for links.

The following small test case fails on:

i686-pc-linux-gnu with gcc 2.95.1 using ld 2.9.5.
i686-unknown-freebsdelf with gcc 2.95.2 (+branch patches) using ld 2.9.5
i686-unknown-freebsd3.4 with mainline CVS gcc using ld 2.10
sparc-sun-solaris2.6 with gcc 2.95.2 using ld 2.10

with this command line (which I tried to capture in the proper place
and manner of the testsuite in the actual patch I am submitting):

g++ -ffunction-sections -fdata-sections -Wl,--gc-sections -static 6.cc; a.out

2000-06-16  Loren J. Rittle  <ljrittle@acm.org>

        * ld-selective/selective.exp:  Add test6.
        * ld-selective/6.cc: New file.

Index: ld-selective/selective.exp
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-selective/selective.exp,v
retrieving revision 1.3.2.1
diff -c -p -r1.3.2.1 selective.exp
*** selective.exp	2000/04/11 23:04:03	1.3.2.1
--- selective.exp	2000/06/17 01:09:45
*************** set test2 "selective2"
*** 32,37 ****
--- 32,38 ----
  set test3 "selective3"
  set test4 "selective4"
  set test5 "selective5"
+ set test6 "selective6"
  
  set cflags "-w -O2 -ffunction-sections -fdata-sections" 
  set cxxflags "-fvtable-gc -fno-exceptions -fno-rtti"
*************** if ![ld_simple_link $ld tmpdir/4.x "$ldf
*** 169,174 ****
--- 170,196 ----
            } else {
  	      pass $test5
               }
+ 	}
+     }
+ }
+ 
+ if [isnative] {
+     if ![ld_compile "$CC $cflags $cxxflags -fexceptions" \
+ 	    $srcdir/$subdir/6.cc tmpdir/6.o] {
+         unresolved $test6
+         return
+     }
+ 
+     if ![ld_link $ld tmpdir/6.x "$ldflags tmpdir/6.o"] {
+         fail $test6
+     } else {
+ 	catch "exec tmpdir/6.x" exec_output
+ 	if ![string match "" $exec_output] then {
+ 	    send_log "$exec_output\n"
+             verbose "$exec_output" 1
+             fail $test6
+ 	} else {
+ 	    pass $test6
  	}
      }
  }
*** /dev/null	Fri Jun 16 19:59:00 2000
--- ld-selective/6.cc	Fri Jun 16 19:19:21 2000
***************
*** 0 ****
--- 1,9 ----
+ int main (void)
+ {
+   try
+     {
+       throw 1;
+     }
+   catch (...) {}
+   return 0;
+ }