svn commit: r339876 - head/libexec/rtld-elf
Mark Millard
marklmi26-fbsd at yahoo.com
Tue Oct 30 19:45:20 UTC 2018
Konstantin Belousov kostikbel at gmail.com wrote on
Tue Oct 30 18:04:04 UTC 2018 :
> On Tue, Oct 30, 2018 at 03:32:40PM +0000, Alexander Richardson wrote:
> > On Tue, 30 Oct 2018 at 10:17, Michael Tuexen
> > <Michael.Tuexen at macmic.franken.de> wrote:
> > >
> > > > On 29. Oct 2018, at 22:08, Alex Richardson <arichardson at FreeBSD.org> wrote:
> > > >
> > > > Author: arichardson
> > > > Date: Mon Oct 29 21:08:02 2018
> > > > New Revision: 339876
> > > > URL: https://svnweb.freebsd.org/changeset/base/339876
> > > >
> > > > Log:
> > > > rtld: set obj->textsize correctly
> > > >
> > > > With lld-generated binaries the first PT_LOAD will usually be a read-only
> > > > segment unless you pass --no-rosegment. For those binaries the textsize is
> > > > determined by the next PT_LOAD. To allow both LLD and bfd 2.17 binaries to
> > > > be parsed correctly use the end of the last PT_LOAD that is marked as
> > > > executable instead.
> > > >
> > > > I noticed that the value was wrong while adding some debug prints for some rtld
> > > > changes for CHERI binaries. `obj->textsize` only seems to be used by PPC so the
> > > > effect is untested. However, the value before was definitely wrong and the new
> > > > result matches the phdrs.
> > > I build kernel and world with a revision later than this on a PPC. Buildword
> > > ends up with a world where almost all binaries are segfaulting.... Especially gdb
> > > (but svn, ls or so all segfault).
> > >
> > > Best regards
> > > Michael
> >
> > This is rather surprising since if anything the range of the icache
> > flush should increase rather than decrease after this change.
> >
> > I can only see this causing a behaviour change if we actually need to
> > flush more than just the executable segments.
> > Is it possible that some binary/library contains a non-executable
> > segment as the first PT_LOAD?
> > Or is there some linker script that adds custom PHDRS?
> >
> Could it be that there is a hole between start of the object mapping and
> the last PT_LOADable segment eligible for execution ?
[This note may be easier to deal with than the first
note that I sent out.]
[My examples are from devel/powerpc64-xtoolchain-gcc used
to buildworld buildkernel targeting a head -r339076 based
powerpc64 environment. I do that on powerpc64 as well.]
powerpc64 loads the readonly data and the readonly code in one PT_LOAD,
the first. The 2nd PT_LOAD is for sections without the readonly status,
that includes .got and .plt being spanned. See below from
objdump -ph for /bin/ls :
Program Header:
PHDR off 0x0000000000000040 vaddr 0x0000000010000040 paddr 0x0000000010000040 align 2**3
filesz 0x0000000000000188 memsz 0x0000000000000188 flags r--
INTERP off 0x00000000000001c8 vaddr 0x00000000100001c8 paddr 0x00000000100001c8 align 2**0
filesz 0x0000000000000015 memsz 0x0000000000000015 flags r--
LOAD off 0x0000000000000000 vaddr 0x0000000010000000 paddr 0x0000000010000000 align 2**16
filesz 0x000000000000910c memsz 0x000000000000910c flags r-x
LOAD off 0x0000000000009110 vaddr 0x0000000010019110 paddr 0x0000000010019110 align 2**16
filesz 0x0000000000000ee0 memsz 0x00000000000010e8 flags rw-
DYNAMIC off 0x0000000000009138 vaddr 0x0000000010019138 paddr 0x0000000010019138 align 2**3
filesz 0x00000000000001c0 memsz 0x00000000000001c0 flags rw-
NOTE off 0x00000000000001e0 vaddr 0x00000000100001e0 paddr 0x00000000100001e0 align 2**2
filesz 0x0000000000000030 memsz 0x0000000000000030 flags r--
STACK off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**4
filesz 0x0000000000000000 memsz 0x0000000000000000 flags rw-
Sections:
Idx Name Size VMA LMA File off Algn
0 .interp 00000015 00000000100001c8 00000000100001c8 000001c8 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .note.tag 00000030 00000000100001e0 00000000100001e0 000001e0 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .hash 0000027c 0000000010000210 0000000010000210 00000210 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .dynsym 00000870 0000000010000490 0000000010000490 00000490 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .dynstr 0000035a 0000000010000d00 0000000010000d00 00000d00 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .gnu.version 000000b4 000000001000105a 000000001000105a 0000105a 2**1
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .gnu.version_r 00000050 0000000010001110 0000000010001110 00001110 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .rela.dyn 00000198 0000000010001160 0000000010001160 00001160 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 .rela.plt 000006f0 00000000100012f8 00000000100012f8 000012f8 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
9 .init 0000002c 00000000100019f0 00000000100019f0 000019f0 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
10 .text 00007204 0000000010001a20 0000000010001a20 00001a20 2**5
CONTENTS, ALLOC, LOAD, READONLY, CODE
11 .fini 00000024 0000000010008c30 0000000010008c30 00008c30 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
12 .rodata 000004b0 0000000010008c58 0000000010008c58 00008c58 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
13 .eh_frame 00000004 0000000010009108 0000000010009108 00009108 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
14 .ctors 00000010 0000000010019110 0000000010019110 00009110 2**3
CONTENTS, ALLOC, LOAD, DATA
15 .dtors 00000010 0000000010019120 0000000010019120 00009120 2**3
CONTENTS, ALLOC, LOAD, DATA
16 .jcr 00000008 0000000010019130 0000000010019130 00009130 2**3
CONTENTS, ALLOC, LOAD, DATA
17 .dynamic 000001c0 0000000010019138 0000000010019138 00009138 2**3
CONTENTS, ALLOC, LOAD, DATA
18 .opd 00000468 00000000100192f8 00000000100192f8 000092f8 2**3
CONTENTS, ALLOC, LOAD, DATA
19 .got 00000098 0000000010019800 0000000010019800 00009800 2**8
CONTENTS, ALLOC, LOAD, DATA
20 .plt 00000708 0000000010019898 0000000010019898 00009898 2**3
ALLOC
21 .data 00000050 0000000010019fa0 0000000010019fa0 00009fa0 2**3
CONTENTS, ALLOC, LOAD, DATA
22 .bss 00000208 0000000010019ff0 0000000010019ff0 00009ff0 2**3
ALLOC
23 .comment 000002b5 0000000000000000 0000000000000000 00009ff0 2**0
CONTENTS, READONLY
24 .gnu_debuglink 00000010 0000000000000000 0000000000000000 0000a2a8 2**2
CONTENTS, READONLY
Note: elfdump indicates a section before what above is
listed as "0 .interp", but the section has sh_name
empty and SHT_NULL as elfdump reports it. Also elfdump
always shows sh_flags as empty, unlike what objdump
reports.
section header:
entry: 0
sh_name:
sh_type: SHT_NULL
sh_flags:
sh_addr: 0
sh_offset: 0
sh_size: 0
sh_link: 0
sh_info: 0
sh_addralign: 0
sh_entsize: 0
So elfdump "entry" numbers for section headers
that have matches in the objdump output are
one larger than the section "Idx" objdump lists.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
More information about the svn-src-head
mailing list