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) _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"