From owner-svn-src-head@freebsd.org Tue Oct 30 19:45:20 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08FB110F286A for ; Tue, 30 Oct 2018 19:45:20 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic306-21.consmr.mail.ne1.yahoo.com (sonic306-21.consmr.mail.ne1.yahoo.com [66.163.189.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 788267669D for ; Tue, 30 Oct 2018 19:45:19 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: YsHzZgIVM1k1AXliVA_VUUHXUWqyMqFeEeQwqGJvOvp68alAChgZRZcM3AEH0cq mD0wpTtpoaKlx4tP3QRiCHbMWkTBlPnZMlBCbb_yznpmghKtIUcBVY9L2GcEIQNsl8x9LKp08U_Y qcb8qqT2xr6B0g_A3Pu2pfBU1ePmzq7PKBZNgbtpXimxoa.aLcykjGULZbJlqLeXVOPLxXGiIMvK DPhhv6KxhOGWB1Fikw89ek4ZA4PMU4URpkKVy1FiYXYgOyIhZ5.a8Ajdk7axTHaVM1bMoFn8Pesf XHIyYbxWdidVzxi0UFVqf5d60.kwhf_t6tHyzKWpXpV8L1SZV9zialamaaGdDtD_VBxLgp9Tm_Ov rUy4gfwuuN6l9pgvTuviF7hpVLRErxa2UpD.MJRbyxA3YunhzYeoYLwJBuDbYdfBNB0SUYHIBAz1 4PQjtP2LBWhBhILdihcB6iPmZGJrs7hKlIQ6E5eTa82tRaa2Qbxw7oVVnf4wrEiNF8Flp2h9HVRm oi9kjc05W8KVmaGu2nw02.510It0oN_mVabVvxPd_u8wWBlnPOXF.qQ_H.RYoqhgEX313j79360n HE_3DwRltRyUQTy124xW_khir_nKtwiTCoQ4CNdzeeL4IN5MilsqErBA.ogSi2S2XImUmIRrK8rH h35NeVhPEhkwwjo6zlIj7sopdMkTXYyZZSsxNXdbR0faKfQDSxL9SNEslWn4Ii7W0KJGQk7W7Zim MGfWawMgjXR8..Udpdqzx0D3YPHtynUUwUsDgzGxDJUXVamGkvS0tdP.1Q7v4UfaZ05aNcwwzVAa S.HrM5ynkt38pUmDJ5Wcw9I_hJuQDfAoh3ID.rwpIA90HPzQz3uh8RdudTYnNvupfzCGf3DhY551 o2Xyl995ek6MUfpYZxOmP1dsdvMOdI0y39LZVhIazdtnI23ns5rYhhuKEv6za6eNTWj3g9aUAeYY y_YM5Cbu2hejrfQZGjiyf6tZxM8G0j4GIXW_6op_rZDId8j234lF0Oph03V_0XS6X1FoSMuymig9 2hJMEk6uJSXIFjUEXrF.0woDeByVfHrmizueU394pm8Cz0U.g6CHf Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Tue, 30 Oct 2018 19:45:18 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp407.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 411143cf21f8b22ab1c738ac3be9554c; Tue, 30 Oct 2018 19:45:14 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: svn commit: r339876 - head/libexec/rtld-elf Message-Id: <8E5A5F3A-F1A7-4702-A2F7-65D74CC5B2E5@yahoo.com> Date: Tue, 30 Oct 2018 12:45:13 -0700 To: Konstantin Belousov , svn-src-head@freebsd.org X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 19:45:20 -0000 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 > > wrote: > > > > > > > On 29. Oct 2018, at 22:08, Alex Richardson 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)