Bug 5149 - PT_GNU_RELRO having PF_R|PF_E even when no section in it needs exec is a ld bug
Summary: PT_GNU_RELRO having PF_R|PF_E even when no section in it needs exec is a ld bug
Status: WAITING
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.19
: P2 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
: 5176 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-10-09 14:42 UTC by Tom Callaway
Modified: 2009-03-11 10:08 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
ld bits that make strange sparc file which fails elfutils test (669.55 KB, application/x-bzip)
2007-10-10 18:22 UTC, Tom Callaway
Details
make libelf.so with -Wl,-verbose and gcc -v (3.81 KB, text/plain)
2007-10-17 08:58 UTC, Oliver Falk
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Callaway 2007-10-09 14:42:17 UTC
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
Comment 1 H.J. Lu 2007-10-10 18:05:44 UTC
If you can provide a testcase, I will look into it.
Comment 2 Tom Callaway 2007-10-10 18:09:43 UTC
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.
Comment 3 H.J. Lu 2007-10-10 18:12:59 UTC
I don't have a Sparc. I can build a cross linker. I need all linker inputs
to reproduce it.
Comment 4 Tom Callaway 2007-10-10 18:21:53 UTC
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.
Comment 5 Tom Callaway 2007-10-10 18:22:35 UTC
Created attachment 2039 [details]
ld bits that make strange sparc file which fails elfutils test
Comment 6 H.J. Lu 2007-10-10 22:04:28 UTC
(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.
Comment 7 Tom Callaway 2007-10-11 14:59:51 UTC
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.
Comment 8 H.J. Lu 2007-10-11 15:49:34 UTC
[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.
Comment 9 H.J. Lu 2007-10-15 16:33:13 UTC
*** Bug 5176 has been marked as a duplicate of this bug. ***
Comment 10 Oliver Falk 2007-10-16 07:06:43 UTC
(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!
Comment 11 Oliver Falk 2007-10-16 09:13:08 UTC
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>
Comment 12 H.J. Lu 2007-10-16 16:06:51 UTC
(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.
Comment 13 Oliver Falk 2007-10-17 08:58:02 UTC
Created attachment 2046 [details]
make libelf.so with -Wl,-verbose and gcc -v
Comment 14 Oliver Falk 2007-10-17 08:59:28 UTC
(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.
Comment 15 Oliver Falk 2007-10-17 09:14:17 UTC
Please find the tarball of my elfutils 0.130 compiled on alpha here:
http://filelister.linux-kernel.at/mod_perl?current=/share
Comment 16 H.J. Lu 2007-10-17 15:23:07 UTC
(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.
Comment 17 Oliver Falk 2007-10-22 08:10:25 UTC
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 
Comment 18 Oliver Falk 2007-10-22 08:12:08 UTC
You can find the mentioned tarball at the same location...
Comment 19 H.J. Lu 2007-10-22 22:31:40 UTC
A patch is posted at

http://sourceware.org/ml/binutils/2007-10/msg00308.html
Comment 20 Oliver Falk 2007-10-23 07:48:43 UTC
> http://sourceware.org/ml/binutils/2007-10/msg00308.html

Can you attach the patch here as well in a 'downloadable' format?
Comment 21 H.J. Lu 2007-10-23 13:28:57 UTC
(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
Comment 22 Oliver Falk 2007-10-23 14:25:52 UTC
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]
Comment 23 Oliver Falk 2007-10-23 14:27:34 UTC
Message spotted by elfutils is still the same of course:
loadable segment GNU_RELRO applies to is executable
*** failure in ../libelf/libelf.so
Comment 24 H.J. Lu 2007-10-23 14:32:06 UTC
(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.
Comment 25 Oliver Falk 2007-10-23 15:01:30 UTC
> 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...
Comment 26 Oliver Falk 2007-10-31 12:20:13 UTC
Will this fix be included in the next release?
Comment 27 H.J. Lu 2007-10-31 14:19:16 UTC
(In reply to comment #26)
> Will this fix be included in the next release?

Have you verified that my fix resolves your problem?
Comment 28 Oliver Falk 2007-11-04 12:50:06 UTC
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?
Comment 29 H.J. Lu 2007-11-04 14:25:49 UTC
(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?
Comment 30 Oliver Falk 2007-11-04 22:36:29 UTC
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
Comment 31 H.J. Lu 2007-11-05 00:19:11 UTC
(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.
Comment 32 Oliver Falk 2007-11-19 13:51:09 UTC
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?
Comment 33 Oliver Falk 2009-03-11 10:08:50 UTC
Ping?