I caught this bug running the elfutils test suite on sparc (see Red Hat Bugzilla 324031). I'm quoting Roland McGrath, who helped track this down: Tom noticed that elflint is giving "loadable segment GNU_RELRO applies to is executable" for a DSO on sparc (RHBZ#324031). See the layout after FF below for reference. The diagnosis is accurate: p_flags has P_X in both PT_GNU_RELRO and the PT_LOAD covering that address range. This bit is "correct" in the PT_LOAD in that there is a SHF_EXECINSTR|SHF_WRITE .plt section in that segment. The bit in PT_GNU_RELRO is dubious, since no SHF_EXECINSTR section falls inside its address range (not that p_flags in PT_GNU_RELRO really matters). This relro region ends cleanly at a page boundary. So I think what elflint would be happy with is splitting that second PT_LOAD into one PF_R|PF_W that ends where PT_GNU_RELRO ends, and a third PT_LOAD with PF_R|PF_W|PF_X that covers .got through .bss. This is clean in this example, but in the general case I don't know how it flies. I think this particular example may just be one with a lucky happenstance, because the relro segment ends exactly on a page boundary just due to the size of the sections. With different details, or e.g. -z now where the .plt itself would go into relro, then there would be a problem. ld.so does not honor the p_flags either of the PT_LOAD or the PT_GNU_RELRO when it applies PT_GNU_RELRO, it just mprotect's the area with PROT_READ. So elflint is right to cite this as a problem. When PT_GNU_RELRO is applied, then the PF_X/PROT_EXEC required by the PT_LOAD is no longer in force. I'm not exactly sure what the right fix is here. It seems like -z now should put .plt in relro, which means it really does need to start out writable and then ld.so has to use PROT_READ|PROT_EXEC. But for this example (no -z now), it seems preferable to apply the relro as now. It just seems unkosher when the PT_LOAD says PF_X. Kosherifying with two PT_LOADs would mean two mmap's now. We could first make ld.so optimize adjacent PT_LOADs with the same protections into a single mmap, and then special-case a PT_LOAD whose pages are all going to be touched later by relro so we roll it into any adjacent PT_LOAD with p_flags&PF_W. Then we'd get back to the same one mmap + mprotect for the same region we have now. I'm sure there are at least two cases I'm not thinking through. There are 38 section headers, starting at offset 0xa5664: Section Headers: [Nr] Name Type Addr Off Size ES Flags Lk Inf Al [ 0] NULL 00000000 000000 000000 0 0 0 0 [ 1] .note.gnu.build-id NOTE 00000114 000114 000024 0 A 0 0 4 [ 2] .gnu.hash GNU_HASH 00000138 000138 0003b4 4 A 3 0 4 [ 3] .dynsym DYNSYM 000004ec 0004ec 000930 16 A 4 3 4 [ 4] .dynstr STRTAB 00000e1c 000e1c 00073c 0 A 0 0 1 [ 5] .gnu.version GNU_versym 00001558 001558 000126 2 A 3 0 2 [ 6] .gnu.version_d GNU_verdef 00001680 001680 0000a4 0 A 4 5 4 [ 7] .gnu.version_r GNU_verneed 00001724 001724 000070 0 A 4 1 4 [ 8] .rela.dyn RELA 00001794 001794 0007d4 12 A 3 0 4 [ 9] .rela.plt RELA 00001f68 001f68 0001d4 12 A 3 22 4 [10] .init PROGBITS 00002140 002140 000038 0 AX 0 0 32 [11] .text PROGBITS 00002180 002180 015360 0 AX 0 0 32 [12] .fini PROGBITS 000174e0 0174e0 000030 0 AX 0 0 32 [13] .rodata PROGBITS 00017510 017510 0014b0 0 A 0 0 8 [14] .eh_frame_hdr PROGBITS 000189c0 0189c0 0003e4 0 A 0 0 4 [15] .eh_frame PROGBITS 00018da4 018da4 000b6c 0 A 0 0 4 [16] .ctors PROGBITS 00029e50 019e50 000008 0 WA 0 0 4 [17] .dtors PROGBITS 00029e58 019e58 000008 0 WA 0 0 4 [18] .jcr PROGBITS 00029e60 019e60 000004 0 WA 0 0 4 [19] .data.rel.ro PROGBITS 00029e64 019e64 0000c4 0 WA 0 0 4 [20] .dynamic DYNAMIC 00029f28 019f28 0000d8 8 WA 4 0 4 [21] .got PROGBITS 0002a000 01a000 0001dc 4 WA 0 0 4 [22] .plt PROGBITS 0002a1dc 01a1dc 000208 0 WAX 0 0 4 [23] .data PROGBITS 0002a3e4 01a3e4 000004 0 WA 0 0 4 [24] .bss NOBITS 0002a3e8 01a3e8 000020 0 WA 0 0 4 [25] .comment PROGBITS 00000000 01a3e8 00147c 0 0 0 1 [26] .debug_aranges PROGBITS 00000000 01b864 000d60 0 0 0 1 [27] .debug_pubnames PROGBITS 00000000 01c5c4 001034 0 0 0 1 [28] .debug_info PROGBITS 00000000 01d5f8 060c6e 0 0 0 1 [29] .debug_abbrev PROGBITS 00000000 07e266 00b652 0 0 0 1 [30] .debug_line PROGBITS 00000000 0898b8 0096ae 0 0 0 1 [31] .debug_frame PROGBITS 00000000 092f68 0015c0 0 0 0 4 [32] .debug_str PROGBITS 00000000 094528 002244 1 MS 0 0 1 [33] .debug_loc PROGBITS 00000000 09676c 00a905 0 0 0 1 [34] .debug_ranges PROGBITS 00000000 0a1071 004480 0 0 0 1 [35] .shstrtab STRTAB 00000000 0a54f1 000171 0 0 0 1 [36] .symtab SYMTAB 00000000 0a5c54 001c80 16 37 312 4 [37] .strtab STRTAB 00000000 0a78d4 001a24 0 0 0 1 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x00000000 0x00000000 0x019910 0x019910 R E 0x10000 LOAD 0x019e50 0x00029e50 0x00029e50 0x000598 0x0005b8 RWE 0x10000 DYNAMIC 0x019f28 0x00029f28 0x00029f28 0x0000d8 0x0000d8 RW 0x4 NOTE 0x000114 0x00000114 0x00000114 0x000024 0x000024 R 0x4 GNU_EH_FRAME 0x0189c0 0x000189c0 0x000189c0 0x0003e4 0x0003e4 R 0x4 GNU_STACK 0x000000 0x00000000 0x00000000 0x000000 0x000000 RW 0x4 GNU_RELRO 0x019e50 0x00029e50 0x00029e50 0x0001b0 0x0001b0 R E 0x1 Section to Segment mapping: Segment Sections... 00 [RO: .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_d .gnu.version_r .rela.dyn .rela.plt .init .text .fini .rodata .eh_frame_hdr .eh_frame] 01 [RELRO: .ctors .dtors .jcr .data.rel.ro .dynamic] .got .plt .data .bss 02 [RELRO: .dynamic] 03 [RO: .note.gnu.build-id] 04 [RO: .eh_frame_hdr] 05 06 [RELRO: .ctors .dtors .jcr .data.rel.ro .dynamic] b
If you can provide a testcase, I will look into it.
Building elfutils on sparc triggers this (running make check against itself). If you have access to a sparc, you should be able to pull this off.
I don't have a Sparc. I can build a cross linker. I need all linker inputs to reproduce it.
OK, let me know if this isn't what you need: The file which fails the test links like this: ar cru libelf_pic.a elf_version.os elf_hash.os elf_error.os elf_fill.os elf_begin.os elf_next.os elf_rand.os elf_end.os elf_kind.os gelf_getclass.os elf_getbase.os elf_getident.os elf32_fsize.os elf64_fsize.os gelf_fsize.os elf32_xlatetof.os elf32_xlatetom.os elf64_xlatetof.os elf64_xlatetom.os gelf_xlate.os elf32_getehdr.os elf64_getehdr.os gelf_getehdr.os elf32_newehdr.os elf64_newehdr.os gelf_newehdr.os gelf_update_ehdr.os elf32_getphdr.os elf64_getphdr.os gelf_getphdr.os elf32_newphdr.os elf64_newphdr.os gelf_newphdr.os gelf_update_phdr.os elf_getarhdr.os elf_getarsym.os elf_rawfile.os elf_readall.os elf_cntl.os elf_getscn.os elf_nextscn.os elf_ndxscn.os elf_newscn.os elf32_getshdr.os elf64_getshdr.os gelf_getshdr.os gelf_update_shdr.os elf_strptr.os elf_rawdata.os elf_getdata.os elf_newdata.os elf_flagelf.os elf_flagehdr.os elf_flagphdr.os elf_flagscn.os elf_flagshdr.os elf_flagdata.os elf_memory.os elf_update.os elf32_updatenull.os elf64_updatenull.os elf32_updatefile.os elf64_updatefile.os gelf_getsym.os gelf_update_sym.os gelf_getversym.os gelf_getverneed.os gelf_getvernaux.os gelf_getverdef.os gelf_getverdaux.os gelf_getrel.os gelf_getrela.os gelf_update_rel.os gelf_update_rela.os gelf_getdyn.os gelf_update_dyn.os gelf_getmove.os gelf_update_move.os gelf_getsyminfo.os gelf_update_syminfo.os gelf_xlatetof.os gelf_xlatetom.os nlist.os gelf_getsymshndx.os gelf_update_symshndx.os gelf_update_versym.os gelf_update_verneed.os gelf_update_vernaux.os gelf_update_verdef.os gelf_update_verdaux.os elf_getshnum.os elf_getshstrndx.os gelf_checksum.os elf32_checksum.os elf64_checksum.os gelf_rawchunk.os gelf_freechunk.os libelf_crc32.os libelf_next_prime.os elf_clone.os gelf_getlib.os gelf_update_lib.os elf32_offscn.os elf64_offscn.os gelf_offscn.os elf_getaroff.os elf_gnu_hash.os ranlib libelf_pic.a gcc -Wall -Wshadow -Werror -Wunused -Wextra -Wformat=2 -std=gnu99 -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -mcpu=ultrasparc -fexceptions -o libelf.so -shared -o libelf.so -Wl,--whole-archive,libelf_pic.a,--no-whole-archive \ -Wl,--version-script,./libelf.map,--no-undefined \ -Wl,--soname,libelf.so.1,-z,-defs,-z,relro I'm attaching the libelf_pic.a, libelf.map, and the bits that make up libelf_pic.a.
Created attachment 2039 [details] ld bits that make strange sparc file which fails elfutils test
(In reply to comment #5) > Created an attachment (id=2039) > ld bits that make strange sparc file which fails elfutils test > That is not enough. Please use "gcc -v" to see all linker inputs and double check them by running linker by hand.
I'm not sure what you need here. bash-3.2# gcc -v Using built-in specs. Target: sparc64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-long-double-128 --host=sparc64-redhat-linux --build=sparc64-redhat-linux --target=sparc64-redhat-linux --with-cpu=v7 Thread model: posix gcc version 4.1.2 20070821 (Red Hat 4.1.2-25) I can give you remote access to this system if it would make things easier, just drop me an email.
[hjl@gnu-6 tmp]$ gcc -v x.o ... /usr/libexec/gcc/x86_64-redhat-linux/4.1.2/collect2 --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtbegin.o -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 x.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtend.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crtn.o It shows all linker input files. I need all of them. You add "-Wl,-verbose" to see which files are used by linker.
*** Bug 5176 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > *** Bug 5176 has been marked as a duplicate of this bug. *** Oh well. My alpha bug is really the same as this sparc bug. :-) If anyone needs any input, let me know!
With latest and greatest elfutils it has gone worse: <snip> loadable segment GNU_RELRO applies to is executable *** failure in ../libelf/libelf.so FAIL: run-elflint-self.sh </snip> <snip> --- readelf.out 2007-10-16 11:00:54.000000000 +0200 +++ - 2007-10-16 11:00:54.118131000 +0200 @@ -1,3 +1,3 @@ Hex dump of section [6] '.strtab', 1 bytes at offset 0x290: - 0x00000000 00 . + 0x00000000 00 . FAIL: run-readelf-test2.sh </snip>
(In reply to comment #10) > (In reply to comment #9) > > *** Bug 5176 has been marked as a duplicate of this bug. *** > > Oh well. My alpha bug is really the same as this sparc bug. :-) > If anyone needs any input, let me know! I need ALL linker input from Linux/alpha.
Created attachment 2046 [details] make libelf.so with -Wl,-verbose and gcc -v
(In reply to comment #13) > Created an attachment (id=2046) > make libelf.so with -Wl,-verbose and gcc -v Linker input files listed in the log. I'll now create a tarball of my elfutils build. Then you should have everything that you need.
Please find the tarball of my elfutils 0.130 compiled on alpha here: http://filelister.linux-kernel.at/mod_perl?current=/share
(In reply to comment #15) > Please find the tarball of my elfutils 0.130 compiled on alpha here: > http://filelister.linux-kernel.at/mod_perl?current=/share (In reply to comment #15) > Please find the tarball of my elfutils 0.130 compiled on alpha here: > http://filelister.linux-kernel.at/mod_perl?current=/share It is incomplete. All system files are missing. Please verify them with a cross linker on Linux/x86.
OK, then this should be what you need, right? [oliver@gosa ~]$ tar tfvj elfutils-system-linker-input-files.tar.bz2 -rw-r--r-- root/root 1496 2007-07-31 23:10 usr/lib/crti.o -rw-r--r-- root/root 3560 2007-09-29 21:41 usr/lib/gcc/alpha-redhat-linux/4.1.2/crtbeginS.o -rw-r--r-- root/root 140288 2007-09-29 21:57 usr/lib/gcc/alpha-redhat-linux/4.1.2/libgcc.a lrwxrwxrwx root/root 0 2007-10-11 12:37 usr/lib/gcc/alpha-redhat-linux/4.1.2/libgcc_s.so -> /lib/libgcc_s.so.1 -rw-r--r-- root/root 241 2007-07-31 20:40 usr/lib/libc.so lrwxrwxrwx root/root 0 2007-08-03 22:36 lib/libc.so.6.1 -> libc-2.6.so -rw-r--r-- root/root 20430 2007-08-01 02:20 usr/lib/libc_nonshared.a lrwxrwxrwx root/root 0 2007-08-03 22:36 lib/ld-linux.so.2 -> ld-2.6.so -rw-r--r-- root/root 140288 2007-09-29 21:57 usr/lib/gcc/alpha-redhat-linux/4.1.2/libgcc.a lrwxrwxrwx root/root 0 2007-10-11 12:37 usr/lib/gcc/alpha-redhat-linux/4.1.2/libgcc_s.so -> /lib/libgcc_s.so.1 -rw-r--r-- root/root 2056 2007-09-29 21:41 usr/lib/gcc/alpha-redhat-linux/4.1.2/crtendS.o -rw-r--r-- root/root 792 2007-07-31 23:10 usr/lib/crtn.o lrwxrwxrwx root/root 0 2007-10-11 12:32 lib/libgcc_s.so.1 -> libgcc_s-4.1.2-20070925.so.1 -rwxr-xr-x root/root 1906056 2007-08-01 02:10 lib/libc-2.6.so -rwxr-xr-x root/root 160384 2007-08-01 02:10 lib/ld-2.6.so lrwxrwxrwx root/root 0 2007-10-11 12:32 lib/libgcc_s.so.1 -> libgcc_s-4.1.2-20070925.so.1 -rwxr-xr-x root/root 65448 2007-09-29 21:57 lib/libgcc_s-4.1.2-20070925.so.1 [oliver@gosa ~]$ tar tfvj elfutils-system-linker-input-files.tar.bz2
You can find the mentioned tarball at the same location...
A patch is posted at http://sourceware.org/ml/binutils/2007-10/msg00308.html
> http://sourceware.org/ml/binutils/2007-10/msg00308.html Can you attach the patch here as well in a 'downloadable' format?
(In reply to comment #20) > > http://sourceware.org/ml/binutils/2007-10/msg00308.html > > Can you attach the patch here as well in a 'downloadable' format? You can use raw text: http://sourceware.org/cgi-bin/get-raw-msg?listname=binutils&date=2007-10&msgid=20071022223109.GA14599%40lucon.org
I rebuilt binutils with your patch and elfutils still complains: [oliver@gosa elfutils-0.130]$ eu-readelf -Sl libelf/libelf.so There are 37 section headers, starting at offset 0xd0ad0: Section Headers: [Nr] Name Type Addr Off Size ES Flags Lk Inf Al [ 0] NULL 0000000000000000 00000000 00000000 0 0 0 0 [ 1] .note.gnu.build-id NOTE 00000000000001c8 000001c8 00000024 0 A 0 0 4 [ 2] .gnu.hash GNU_HASH 00000000000001f0 000001f0 00000560 0 A 3 0 8 [ 3] .dynsym DYNSYM 0000000000000750 00000750 00000de0 24 A 4 1 8 [ 4] .dynstr STRTAB 0000000000001530 00001530 0000073b 0 A 0 0 1 [ 5] .gnu.version GNU_versym 0000000000001c6c 00001c6c 00000128 2 A 3 0 2 [ 6] .gnu.version_d GNU_verdef 0000000000001d98 00001d98 000000c0 0 A 4 6 8 [ 7] .gnu.version_r GNU_verneed 0000000000001e58 00001e58 00000050 0 A 4 1 8 [ 8] .rela.dyn RELA 0000000000001ea8 00001ea8 00000558 24 A 3 0 8 [ 9] .rela.plt RELA 0000000000002400 00002400 00000330 24 A 3 21 8 [10] .init PROGBITS 0000000000002730 00002730 00000068 0 AX 0 0 8 [11] .text PROGBITS 00000000000027a0 000027a0 000223e0 0 AX 0 0 16 [12] .fini PROGBITS 0000000000024b80 00024b80 00000040 0 AX 0 0 8 [13] .rodata PROGBITS 0000000000024bc0 00024bc0 00001793 0 A 0 0 8 [14] .eh_frame_hdr PROGBITS 0000000000026354 00026354 0000057c 0 A 0 0 4 [15] .eh_frame PROGBITS 00000000000268d0 000268d0 0000161c 0 A 0 0 8 [16] .ctors PROGBITS 0000000000039c98 00029c98 00000010 0 WA 0 0 8 [17] .dtors PROGBITS 0000000000039ca8 00029ca8 00000010 0 WA 0 0 8 [18] .jcr PROGBITS 0000000000039cb8 00029cb8 00000008 0 WA 0 0 8 [19] .data.rel.ro PROGBITS 0000000000039cc0 00029cc0 00000190 0 WA 0 0 8 [20] .dynamic DYNAMIC 0000000000039e50 00029e50 000001b0 16 WA 4 0 8 [21] .plt PROGBITS 000000000003a000 0002a000 000001b8 0 WAX 0 0 16 [22] .got PROGBITS 000000000003a1b8 0002a1b8 00000140 0 WA 0 0 8 [23] .sdata PROGBITS 000000000003a2f8 0002a2f8 000000a8 0 WA 0 0 8 [24] .sbss NOBITS 000000000003a3a0 0002a3a0 00000030 0 WA 0 0 8 [25] .comment PROGBITS 0000000000000000 0002a3a0 00001456 0 0 0 1 [26] .debug_aranges PROGBITS 0000000000000000 0002b7f6 00001470 0 0 0 1 [27] .debug_pubnames PROGBITS 0000000000000000 0002cc66 00001083 0 0 0 1 [28] .debug_info PROGBITS 0000000000000000 0002dce9 000827dc 0 0 0 1 [29] .debug_abbrev PROGBITS 0000000000000000 000b04c5 0000b1b5 0 0 0 1 [30] .debug_line PROGBITS 0000000000000000 000bb67a 00007f38 0 0 0 1 [31] .debug_frame PROGBITS 0000000000000000 000c35b8 00002a18 0 0 0 8 [32] .debug_str PROGBITS 0000000000000000 000c5fd0 0000665c 0 0 0 1 [33] .debug_loc PROGBITS 0000000000000000 000cc62c 00004339 0 0 0 1 [34] .shstrtab STRTAB 0000000000000000 000d0965 00000165 0 0 0 1 [35] .symtab SYMTAB 0000000000000000 000d1410 000027f0 24 36 279 8 [36] .strtab STRTAB 0000000000000000 000d3c00 000016d1 0 0 0 1 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x027eec 0x027eec R E 0x10000 LOAD 0x029c98 0x0000000000039c98 0x0000000000039c98 0x000708 0x000738 RWE 0x10000 DYNAMIC 0x029e50 0x0000000000039e50 0x0000000000039e50 0x0001b0 0x0001b0 RW 0x8 NOTE 0x0001c8 0x00000000000001c8 0x00000000000001c8 0x000024 0x000024 R 0x4 GNU_EH_FRAME 0x026354 0x0000000000026354 0x0000000000026354 0x00057c 0x00057c R 0x4 GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x8 GNU_RELRO 0x029c98 0x0000000000039c98 0x0000000000039c98 0x000368 0x000368 R 0x1 Section to Segment mapping: Segment Sections... 00 [RO: .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_d .gnu.version_r .rela.dyn .rela.plt .init .text .fini .rodata .eh_frame_hdr .eh_frame] 01 [RELRO: .ctors .dtors .jcr .data.rel.ro .dynamic] .plt .got .sdata .sbss 02 [RELRO: .dynamic] 03 [RO: .note.gnu.build-id] 04 [RO: .eh_frame_hdr] 05 06 [RELRO: .ctors .dtors .jcr .data.rel.ro .dynamic]
Message spotted by elfutils is still the same of course: loadable segment GNU_RELRO applies to is executable *** failure in ../libelf/libelf.so
(In reply to comment #23) > Message spotted by elfutils is still the same of course: > loadable segment GNU_RELRO applies to is executable > *** failure in ../libelf/libelf.so What is wrong with GNU_RELRO? It could be an elfutils bug.
> What is wrong with GNU_RELRO? It could be an elfutils bug. If this looks fine for you then OK. I'll ask elfutils guys then. I just wanted to ask you if it looks OK for you, so I don't bug elfutils for nothing...
Will this fix be included in the next release?
(In reply to comment #26) > Will this fix be included in the next release? Have you verified that my fix resolves your problem?
What in your opinion would be the best way to verify it? elfutils still spot the same problem. So actually, you might have fixed the problem, but elfutils is still having a problem; Or: Your fix didn't help. Shall I send you another eu-readelf?
(In reply to comment #28) > What in your opinion would be the best way to verify it? elfutils still spot the > same problem. So actually, you might have fixed the problem, but elfutils is > still having a problem; Or: Your fix didn't help. Shall I send you another > eu-readelf? What does elfutils complain about? What is wrong with the executable generated by the patched linker?
It still spots the same error: *** failure in ../src/addr2line loadable segment GNU_RELRO applies to is executable *** failure in ../libelf/libelf.so FAIL: run-elflint-self.sh
(In reply to comment #30) > It still spots the same error: > *** failure in ../src/addr2line > loadable segment GNU_RELRO applies to is executable > *** failure in ../libelf/libelf.so > FAIL: run-elflint-self.sh > I think it is a bug in elflint. But you have to verify it with elflint developers.
So. relo has no longer executable flag set - for me this is ok from binutils point of view and the patch should be submitted. I think the problem why elflint still spotting that error is because .plt and relro are in the same segment sections!? Sorry, I'm not a guru in these internals - that's just a guess. <snip> [21] .plt PROGBITS 000000000003a000 0002a000 000001b8 0 WAX 0 0 16 </snip> <snap> 01 [RELRO: .ctors .dtors .jcr .data.rel.ro .dynamic] .plt .got .sdata .sbss </snap> in the last example... Does that sound reasonable for you?
Ping?
I believe this was fixed for binutils a long time ago.