This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [binutils-gdb] Fix the linker so that it will not silently generate ELF binaries with invalid program headers. Fix
- From: "Maciej W. Rozycki" <macro at imgtec dot com>
- To: Nick Clifton <nickc at sourceware dot org>
- Cc: <binutils at sourceware dot org>
- Date: Thu, 8 Dec 2016 09:30:04 +0000
- Subject: Re: [binutils-gdb] Fix the linker so that it will not silently generate ELF binaries with invalid program headers. Fix
- Authentication-results: sourceware.org; auth=none
- References: <20161123111226.62132.qmail@sourceware.org>
Hi Nick,
On Wed, 23 Nov 2016, Nick Clifton wrote:
> commit 1a9ccd70f9a75dc6b48d340059f28ef3550c107b
> Author: Nick Clifton <nickc@redhat.com>
> Date: Wed Nov 23 11:10:39 2016 +0000
>
> Fix the linker so that it will not silently generate ELF binaries with invalid program headers. Fix readelf to report such invalid binaries.
This change has caused a `mips-vxworks' and `mipsel-vxworks' target
regression:
FAIL: VxWorks executable test 2 (dynamic)
and I cannot figure out either from the commit description or the lengthy
Bugzilla discussion whether it is an actual functional VxWorks regression
or whether we can just adjust the regexps in the test case and consider it
handled.
Your commit changed output from this test case from:
Elf file type is EXEC (Executable file)
Entry point 0x80400
There are 5 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x00001034 0x00000000 0x000a0 0x000a0 R E 0x4
INTERP 0x001000 0x00080000 0x00080000 0x00013 0x00013 R 0x1
[Requesting program interpreter: /usr/lib/libc.so.1]
LOAD 0x001000 0x00080000 0x00080000 0x00408 0x00408 R E 0x1000
LOAD 0x002000 0x00081000 0x00081000 0x00804 0x00c00 RW 0x1000
DYNAMIC 0x002000 0x00081000 0x00081000 0x00078 0x00078 RW 0x4
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .hash .dynsym .dynstr .text
03 .dynamic .got .data .rld_map
04 .dynamic
to:
Elf file type is EXEC (Executable file)
Entry point 0x80400
There are 5 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x0007f034 0x0007f034 0x000a0 0x000a0 R E 0x4
INTERP 0x001000 0x00080000 0x00080000 0x00013 0x00013 R 0x1
[Requesting program interpreter: /usr/lib/libc.so.1]
LOAD 0x000000 0x0007f000 0x0007f000 0x01408 0x01408 R E 0x1000
LOAD 0x002000 0x00081000 0x00081000 0x00804 0x00c00 RW 0x1000
DYNAMIC 0x002000 0x00081000 0x00081000 0x00078 0x00078 RW 0x4
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .hash .dynsym .dynstr .text
03 .dynamic .got .data .rld_map
04 .dynamic
This places the first LOAD segment below the location set with the linker
script, which I fear may affect run-time interpretation. The test case
has the addresses expected spelled out in full for a reason I suppose.
Please help with resolving this problem.
Maciej