I enabled -z relro by default (link_info.relro = TRUE; in ldmain.c) This causes some of the testcases in ld to fail: FAIL: strip -z max-page-size=0x200000 (maxpage1) FAIL: strip -z max-page-size=0x200000 -z common-page-size=0x100000 (maxpage1) FAIL: strip -z max-page-size=0x100000 (maxpage1) FAIL: strip -z max-page-size=0x100000 -z common-page-size=0x1000 (maxpage1) FAIL: strip (maxpage1) FAIL: objcopy (maxpage1) FAIL: objcopy (tbss1) FAIL: objcopy -shared (tbss1) FAIL: objcopy -z max-page-size=0x100000 (tbss1) FAIL: objcopy -z max-page-size=0x100000 -z common-page-size=0x1000 (tbss1) FAIL: objcopy (tdata1) FAIL: objcopy -shared (tdata1) FAIL: objcopy -z max-page-size=0x100000 (tdata1) FAIL: objcopy -z max-page-size=0x100000 -z common-page-size=0x1000 (tdata1) FAIL: objcopy (tbss2) FAIL: objcopy -z max-page-size=0x100000 (tbss2) FAIL: objcopy -z max-page-size=0x100000 -z common-page-size=0x1000 (tbss2) FAIL: objcopy -z max-page-size=0x100000 (tdata2) FAIL: objcopy (tdata2) FAIL: objcopy -shared (tdata2) FAIL: objcopy -z max-page-size=0x100000 -z common-page-size=0x1000 (tdata2) The problem with those testcase it, that ld generates a PT_NULL section which is discard by strip and objcopy: --- tmpdir/maxpage1.exp 2006-08-09 06:10:42.000000000 +0000 +++ tmpdir/maxpage1.out 2006-08-09 06:10:42.000000000 +0000 @@ -1,16 +1,14 @@ Elf file type is EXEC (Executable file) Entry point 0x10000094 -There are 3 program headers, starting at offset 52 +There are 2 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x10000000 0x10000000 0x00098 0x00098 R E 0x10000 LOAD 0x001000 0x10011000 0x10011000 0x00004 0x00004 RW 0x10000 - NULL 0x000000 0x00000000 0x00000000 0x00000 0x00000 0 Section to Segment mapping: Segment Sections... 00 .text 01 .data - 02 The PT_NULL section is generated by assign_file_positions_for_non_load_sections(). ld should probably not emit PT_NULL sections.
I would suggest you create a separate testcase with -z relro so that this linker bug is caught.
A testcase to show that -z relro may create PT_NULL segment: [hjl@gnu-16 tmp]$ cat x.s .globl main .globl start .globl _start .globl __start .text main: start: _start: __start: .long 0 [hjl@gnu-16 tmp]$ gcc -c x.s [hjl@gnu-16 tmp]$ ld -z relro x.o [hjl@gnu-16 tmp]$ readelf -l a.out Elf file type is EXEC (Executable file) Entry point 0x4000b0 There are 2 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000 0x00000000000000b4 0x00000000000000b4 R E 200000 NULL 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0 Section to Segment mapping: Segment Sections... 00 .text 01
A patch is posted at http://sourceware.org/ml/binutils/2006-08/msg00166.html
Well, my patch is incorrect. It isn't easy to remove the PT_NULL segment.
This patch http://sourceware.org/ml/binutils/2006-08/msg00187.html works much better.
Fixed.
It is not fixed for all targets. "-z relro" doesn't work on Linux/ia64. Instead of ignoring the option, a PT_NULL segment is created. This patch should fix it: http://sourceware.org/ml/binutils/2006-08/msg00263.html
I'm seeing these fails on hppa-unknown-linux-gnu: FAIL: strip -z relro -shared (maxpage1) FAIL: objcopy -z relro -shared (maxpage1)
The patch fixing Linux/ia64 may also work for Linux/hppa.
Subject: Re: -z relro may create PT_NULL segment > The patch fixing Linux/ia64 may also work for Linux/hppa. It works. Dave
Fixed for Linux/ia64 and Linux/hppa.