Date: Tue, 30 Oct 2018 12:45:13 -0700 From: Mark Millard <marklmi26-fbsd@yahoo.com> To: Konstantin Belousov <kostikbel@gmail.com>, svn-src-head@freebsd.org Subject: Re: svn commit: r339876 - head/libexec/rtld-elf Message-ID: <8E5A5F3A-F1A7-4702-A2F7-65D74CC5B2E5@yahoo.com>
next in thread | raw e-mail | index | archive | help
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 > >=20 > > This is rather surprising since if anything the range of the icache > > flush should increase rather than decrease after this change. > >=20 > > 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? > >=20 > 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:=20 sh_type: SHT_NULL sh_flags:=20 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. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8E5A5F3A-F1A7-4702-A2F7-65D74CC5B2E5>