Shared libraries linked with "-z relro" using gold become unusable when stripped with "--strip-unneeded". Trying to load the so gives "ELF load command address/offset not properly aligned". Problem happens on x86_64, on i686 it works fine. The problem occurs with 2.20.51.0.10 but 2.20.51.0.9 works fine. Tried with gcc 4.3.3 and 4.5.1. Also with binutils self compiled from source and binaries from kernel.org. I have put compiled binaries of zlib [1] and output of readelf -a. [1] http://cekirdek.pardus.org.tr/~onur/goldbug/
Created attachment 4891 [details] readelf -a for bad.so
Created attachment 4892 [details] readelf -a for good.so
See the GNU_RELRO section difference --- good --- GNU_EH_FRAME 0x0000000000013c74 0x0000000000013c74 0x0000000000013c74 0x000000000000036c 0x000000000000036c R 4 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 0 GNU_RELRO 0x000000000001bd00 0x000000000001bd00 0x000000000001bd00 0x0000000000000318 0x0000000000000318 RW 20 Section to Segment mapping: --- bad --- GNU_EH_FRAME 0x0000000000013c74 0x0000000000013c74 0x0000000000013c74 0x000000000000036c 0x000000000000036c R 4 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 0 NULL 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0 Section to Segment mapping:
Looks like a strip bug rather than a gold bug to me. Reclassifying.
Perhaps I was a little hasty in saying this is a strip bug. When looking at "good.so" more carefully, I see some really weird segment values. This one: LOAD 0x01bce8 0x000000000001bce8 0x000000000001bce8 0x000560 0x000570 RW 0x1000 maps in part of the file that is unused by any section. File offset 0x01bce8 is past the end of .plt (0x1a550) but before the start of .data.rel.ro.local (0x1bd00). Also GNU_RELRO 0x01bd00 0x000000000001bd00 0x000000000001bd00 0x000318 0x000318 RW 0x20 doesn't end on a page boundary. Seems like gold is broken if it is creating segments like these. Of course, in an ideal world strip would throw away the bogus GNU_RELRO header and not be confused by the odd LOAD header.
Subject: Bug 11866 CVSROOT: /cvs/src Module name: src Changes by: amodra@sourceware.org 2010-08-02 10:08:02 Modified files: bfd : ChangeLog elf.c Log message: PR 11866 * elf.c (assign_file_positions_for_load_sections): Use p_vaddr to calculate off_adjust rather than first section vma. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/ChangeLog.diff?cvsroot=src&r1=1.5085&r2=1.5086 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elf.c.diff?cvsroot=src&r1=1.513&r2=1.514
What is good.so and how was it created? I don't see how gold could create segment headers that look like that. I do see a problem when I run strip on a shared library generated by gold using - z relro, but I'm not sure it's the same problem that you are seeing. I'll fix that problem in any case.
Subject: Bug 11866 CVSROOT: /cvs/src Module name: src Changes by: ian@sourceware.org 2010-08-02 11:59:12 Modified files: gold : ChangeLog output.cc output.h gold/testsuite : Makefile.am Makefile.in Log message: PR 11866 * output.cc (Output_segment::set_offset): Search for the first and last sections rather than assuming that the list is in order. (Output_segment::find_first_and_last_list): New function. * output.h (class Output_segment): Update declarations. * testsuite/Makefile.am (check_PROGRAMS): Add relro_strip_test. (relro_strip_test_SOURCES): New variable. (relro_strip_test_DEPENDENCIES): New variable. (relro_strip_test_LDFLAGS): New variable. (relro_strip_test_LDADD): New variable. (relro_strip_test.so): New target. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/ChangeLog.diff?cvsroot=src&r1=1.601&r2=1.602 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/output.cc.diff?cvsroot=src&r1=1.130&r2=1.131 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/output.h.diff?cvsroot=src&r1=1.109&r2=1.110 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/testsuite/Makefile.am.diff?cvsroot=src&r1=1.138&r2=1.139 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/testsuite/Makefile.in.diff?cvsroot=src&r1=1.146&r2=1.147
I committed a patch which fixes the problem that I saw. Let me know if you still see a problem.
Applying the patches on top of 2.20.51.0.10 fixes the problem for me, thank you. For the segment headers, guess I have send the wrong files created by a toolchain I am playing with these days. Since I could reproduce with a clean system too, I probably did not notice it and mixed up the files. Sorry for that.