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>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_EF1978AC-F62F-4553-819B-7D35F4D7C9E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 2020-02-23 16:31, Paul Floyd wrote: > I=E2=80=99ve been working on getting Valgrind to work again on = FreeBSD. > Probably the biggest problem at the moment is that Valgrind doesn=E2=80=99= t (yet) handle the read-only program headers. > If I run =E2=80=9Creadelf -l libc++.so.1.0=E2=80=9D on Linux I see two = LOAD headers, the first one =E2=80=9CR E=E2=80=9D (read-execute) and the = second one =E2=80=9CRW=E2=80=9D (read-write). If I do the same on = FreeBSD then I see a third program header which is =E2=80=9CR=E2=80=9D = (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 --Apple-Mail=_EF1978AC-F62F-4553-819B-7D35F4D7C9E2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCXlL53QAKCRCwXqMKLiCW o0k3AKC5NIowfqjaky6Vo+3DD5gO5Im9ZQCZATfSumuduazV5iBXX+0MnW1WRlo= =AL6S -----END PGP SIGNATURE----- --Apple-Mail=_EF1978AC-F62F-4553-819B-7D35F4D7C9E2--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0A123A6C-F16C-4BBE-8816-CA94BCAEBABF>