From owner-svn-src-head@freebsd.org Wed Oct 31 18:38:52 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 7A04D10E1B0C for ; Wed, 31 Oct 2018 18:38:52 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (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 EE03A82D9F for ; Wed, 31 Oct 2018 18:38:51 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: UKl8HpAVM1m9J9adTlWTxlViqpKDc1bjtj12MwkvA70Hoz0dfc7suI0Ub.drkzi FNTbOx0TrolAowdtpmN5qEZ5Nzh6fX9S1r33mvjdFF2RNPsZHkTxapGlF6Pr2rAyCZ0GP7pmAT2t MHLFwFYUAtr4NFOoQmWzfMcW2K.rHRU7hrzo_g1arwrGS6Sqb0_Fvpawi1asbM4GEcTMfqziTmet VIRwWgiA91mu5T6qmK50p35PIzy7iPvxVNh6WCvZvKeEGN.dUD2qNc1Pcs6dJwxRY4XNsq4R8An9 x4E.630DWKES7AfTRwElBLKgroEhM7BQHkwzMG9FxoTdUVJFb5iYfPCclbs4GooCUQTexi6MfMrV n5OfyKbr8P9stHoEzM35rtsqyXpOvfilZQh4vLfd5Be9iY0qYUUj6mE2h9VuEVl.wDeVVBBRuHJl .ULBxvoKK0jBk5_naBpJQvr3YGRWbb2CpIRptb8zXL1GpBSNRCuricUhYQ6sOvcmMfXEjKZ6b4WI ZQYzSJTCGYWpDVJDvkLFv7w0ss08XACvnztRz.EwyWr7yxWlsyuwBNn0sODwvWOi1EYrE_5jtzH0 u4vaiE.jN_DlnNRuugEwFNrcgcza4.yffg5lRPR4XR4OgsZTgHKfmnHzgSyEpACJg3m.Fkx9bcoE xARauZTnaAECsqwZJHJkiB50sxLBg1LU0.lb8Ma37Ik19ncVu56NG9vKE44j_rDJaSbUkvA3Ltls O_Bx2C0Zup8lS9gRXd2uODqWNdzyyMrQIz_4f77IpW5T1Q_TPu2JjsdSu72nRWhDpSzAMX_aPOAO sxJ3DX6cr2hTmdBWxVSkA_6G0tu6ChwyKS8.abzt4EUZ2SrqHPQNdKXUY0LzsE_3q4Wmf8zigVuv kXzvReIX3_R8hZ0MU00d4KARO17s5Fv66NbVBehWsQYMzJknTearB6qtPk3yooFvcDg05GTT5SlC Z2AZoXHCQ.RXKBWHHONseYFrVMHxU96XDaeSNnv5G_axeZ0tI5YviXiiPeRNEX9kdpuLouiDKbb8 YQR9zBPHSAIOl515zgz_XFTYkda.YAuqwIzYi_YCNLsSD7ig- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Wed, 31 Oct 2018 18:38:44 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp430.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 2da2d2961cecf87805b184f9e8b26b99; Wed, 31 Oct 2018 18:38:41 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: svn commit: r339876 - head/libexec/rtld-elf From: Mark Millard In-Reply-To: Date: Wed, 31 Oct 2018 11:38:40 -0700 Cc: svn-src-head@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7DC6D9C4-C153-4BCE-851C-22C890AB0D73@yahoo.com> <2D7C5FC6-CA8D-4AAB-BD64-CC883531F737@yahoo.com> To: Alexander Richardson 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: Wed, 31 Oct 2018 18:38:52 -0000 On 2018-Oct-30, at 3:23 PM, Alexander Richardson wrote: > . . . > Before this change obj->textsize was always set as the end of > PT_LOAD[0]. Now it will contain everything up to the end of the last > PT_LOAD with execute permissions. In the binary you dumped this is > PT_LOAD[0] both before and after the patch so there is no change in > behaviour. The .got and .plt we not included in textsize before this > patch either. Therefore the only way I can see this patch breaking > anything is if the PHDRS of one of the loaded libraries causes a > change in behaviour. A fair night's sleep helps. Not only did I read something into your description that was not there, I looked at powerpc64 when it turns out that only 32-bit powerpc shows the problem. (I asked.) I'm also told reverting just those changes fixes 32-bit powerpc context. So I'm using an older 32-bit powerpc context to look at: = https://artifact.ci.freebsd.org/snapshot/head/r339870/powerpc/powerpc/base= *.txz materials now. -r339870 is the first 32-bit powerpc build available there after the changes were made. So in a /339870/ area from expanding the .txz's inside it I get: # elfdump -p ./bin/ls | less program header: entry: 0 p_type: PT_PHDR p_offset: 52 p_vaddr: 0x1800034 p_paddr: 0x1800034 p_filesz: 224 p_memsz: 224 p_flags: PF_X|PF_R p_align: 4 entry: 1 p_type: PT_INTERP p_offset: 276 p_vaddr: 0x1800114 p_paddr: 0x1800114 p_filesz: 21 p_memsz: 21 p_flags: PF_R p_align: 1 entry: 2 p_type: PT_LOAD p_offset: 0 p_vaddr: 0x1800000 p_paddr: 0x1800000 p_filesz: 34112 p_memsz: 34112 p_flags: PF_X|PF_R p_align: 65536 entry: 3 p_type: PT_LOAD p_offset: 34112 p_vaddr: 0x1818540 p_paddr: 0x1818540 p_filesz: 316 p_memsz: 1752 p_flags: PF_X|PF_W|PF_R p_align: 65536 entry: 4 p_type: PT_DYNAMIC p_offset: 34132 p_vaddr: 0x1818554 p_paddr: 0x1818554 p_filesz: 216 p_memsz: 216 p_flags: PF_W|PF_R p_align: 4 entry: 5 p_type: PT_NOTE p_offset: 300 p_vaddr: 0x180012c p_paddr: 0x180012c p_filesz: 48 p_memsz: 48 p_flags: PF_R p_align: 4 entry: 6 p_type: PT_LOAD p_offset: 0 p_vaddr: 0 p_paddr: 0 p_filesz: 0 p_memsz: 0 p_flags: PF_W|PF_R p_align: 4 I note some things unique to this compared to powerpc64 and to what the old code would do for what is unique: There are 2 PT_LOADS with PF_X and there are a bunch of pages between that are not covered by any entry. This is from p_align being 65536 from what I can tell. entry 2: 0x1800000+34112=3D=3D0x1808540 for the ending of the read-only PF_X = area. entry 3: 0x1818540 for the beginning of the writable PF_X area. 0x0010000 differences: 65536 Bytes. What is the handling of the page range that is not described in any entry? Is __syncicache(obj->mapbase, obj->textsize) spanning the hole valid? Previously the hole was not spanned as I understand. Libraries also have the hole between the PT_LOAD with PF_X ranges. Using /lib/libc.so as an example: # elfdump -p ./lib/libc.so.7 | less program header: entry: 0 p_type: PT_LOAD p_offset: 0 p_vaddr: 0 p_paddr: 0 p_filesz: 1746472 p_memsz: 1746472 p_flags: PF_X|PF_R p_align: 65536 entry: 1 p_type: PT_LOAD p_offset: 1746480 p_vaddr: 0x1ba630 p_paddr: 0x1ba630 p_filesz: 44188 p_memsz: 201536 p_flags: PF_X|PF_W|PF_R p_align: 65536 entry: 2 p_type: PT_DYNAMIC p_offset: 1762600 p_vaddr: 0x1be528 p_paddr: 0x1be528 p_filesz: 192 p_memsz: 192 p_flags: PF_W|PF_R p_align: 4 entry: 3 p_type: PT_TLS p_offset: 1746480 p_vaddr: 0x1ba630 p_paddr: 0x1ba630 p_filesz: 2832 p_memsz: 2860 p_flags: PF_R p_align: 16 entry: 4 p_type: PT_NULL p_offset: 1745288 p_vaddr: 0x1aa188 p_paddr: 0x1aa188 p_filesz: 236 p_memsz: 236 p_flags: PF_R p_align: 4 entry: 5 p_type: PT_LOAD p_offset: 0 p_vaddr: 0 p_paddr: 0 p_filesz: 0 p_memsz: 0 p_flags: PF_W|PF_R p_align: 4 1746472=3D=3D0x1AA628 for the ending of the readonly code. 0x1ba630 for the beginning of the writable code. 0x10008 difference: 655544 bytes. I doubt the following would contribute but I note them: PT_PHDR for ./bin/ls has PF_X indicated. Various other entries overlap with the PT_LOAD's that have PF_X. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)