Date: Sun, 23 Feb 2020 23:17:01 +0100 From: Dimitry Andric <dim@FreeBSD.org> To: Paul Floyd <pjfloyd@wanadoo.fr>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org> Subject: Re: RO Elf program headers Message-ID: <0A123A6C-F16C-4BBE-8816-CA94BCAEBABF@FreeBSD.org> In-Reply-To: <9AAE92C0-4FD7-43DF-A805-EFEE7EA06B56@wanadoo.fr> References: <9AAE92C0-4FD7-43DF-A805-EFEE7EA06B56@wanadoo.fr>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On 2020-02-23 16:31, Paul Floyd wrote: > I’ve been working on getting Valgrind to work again on FreeBSD. > Probably the biggest problem at the moment is that Valgrind doesn’t (yet) handle the read-only program headers. > If I run “readelf -l libc++.so.1.0” on Linux I see two LOAD headers, the first one “R E” (read-execute) and the second one “RW” (read-write). If I do the same on FreeBSD then I see a third program header which is “R” (read-only), before the other two. > My questions are > - Does anyone know when this extra header was added? (I assume that it was added sometime in the past 5 years or so) Most likely a very long time ago. > - What is in these segments, and is it safe to assume that multiple shared libraries can map the same RO content to the same address? If you use readelf -l, you will see a "Section to Segment mapping": $ readelf -lW /usr/lib/libc++.so.1 Elf file type is DYN (Shared object file) Entry point 0x5c000 There are 9 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000040 0x0000000000000040 0x0000000000000040 0x0001f8 0x0001f8 R 0x8 LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x05b1d4 0x05b1d4 R 0x1000 LOAD 0x05c000 0x000000000005c000 0x000000000005c000 0x06bbe0 0x06bbe0 R E 0x1000 LOAD 0x0c8000 0x00000000000c8000 0x00000000000c8000 0x004c78 0x004c78 RW 0x1000 LOAD 0x0cd000 0x00000000000cd000 0x00000000000cd000 0x000de0 0x0032f8 RW 0x1000 DYNAMIC 0x0cc5c0 0x00000000000cc5c0 0x00000000000cc5c0 0x0001a0 0x0001a0 RW 0x8 GNU_RELRO 0x0c8000 0x00000000000c8000 0x00000000000c8000 0x004c78 0x004c78 R 0x1 GNU_EH_FRAME 0x046c34 0x0000000000046c34 0x0000000000046c34 0x003244 0x003244 R 0x4 GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0 Section to Segment mapping: Segment Sections... 00 01 .dynsym .gnu.version .gnu.version_r .gnu.hash .hash .dynstr .rela.dyn .rela.plt .rodata .gcc_except_table .eh_frame_hdr .eh_frame 02 .text .init .fini .plt 03 .ctors .dtors .jcr .data.rel.ro .init_array .dynamic .got 04 .data .got.plt .bss 05 .dynamic 06 .ctors .dtors .jcr .data.rel.ro .init_array .dynamic .got 07 .eh_frame_hdr 08 E.g, segment 01 is R, and contains things like the dynamic symbol table, relocations, exception handling information, and so on. It is fairly safe to say that these can be shared. -Dimitry [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCXlL53QAKCRCwXqMKLiCW o0k3AKC5NIowfqjaky6Vo+3DD5gO5Im9ZQCZATfSumuduazV5iBXX+0MnW1WRlo= =AL6S -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0A123A6C-F16C-4BBE-8816-CA94BCAEBABF>