On Montag, 15. Oktober 2018 23:06:07 CEST Milian Wolff wrote: > On Montag, 15. Oktober 2018 23:04:52 CEST Mark Wielaard wrote: > > Hi Milian, > > > > On Mon, 2018-10-15 at 22:38 +0200, Milian Wolff wrote: > > > here's one example of mmap events recorded by perf: > > > > > > 0x7fac5ec0b000 to 0x7fac5ed9a000, len = 0x18f000, offset > > > = 0 r--p /usr/lib/libstdc++.so.6.0.25 > > > 0x7fac5ec94000 to 0x7fac5ed8a000, len = 0xf6000, offset > > > = 0x89000 ---p /usr/lib/libstdc++.so.6.0.25 > > > 0x7fac5ec94000 to 0x7fac5ed4c000, len = 0xb8000, offset > > > = 0x89000 r-xp /usr/lib/libstdc++.so.6.0.25 > > > 0x7fac5ed4c000 to 0x7fac5ed89000, len = 0x3d000, offset > > > = 0x141000 r--p /usr/lib/libstdc++.so.6.0.25 > > > 0x7fac5ed8a000 to 0x7fac5ed97000, len = 0xd000, offset > > > = 0x17e000 rw-p /usr/lib/libstdc++.so.6.0.25 > > > > Could you also post the matching phdr output for the file? > > eu-readelf -l /usr/lib/libstdc++.so.6.0.25 should show it. > > That way we can see how the PT_LOAD segments map to the mmap events. > > Sure: > > $ eu-readelf -l /usr/lib/libstdc++.so.6.0.25 > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz > MemSiz Flg Align > LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x088fa8 > 0x088fa8 R 0x1000 > LOAD 0x089000 0x0000000000089000 0x0000000000089000 0x0b7ae1 > 0x0b7ae1 R E 0x1000 > LOAD 0x141000 0x0000000000141000 0x0000000000141000 0x03cfe0 > 0x03cfe0 R 0x1000 > LOAD 0x17e8e0 0x000000000017f8e0 0x000000000017f8e0 0x00b8b8 > 0x00ed60 RW 0x1000 > DYNAMIC 0x1873a8 0x00000000001883a8 0x00000000001883a8 0x0001e0 > 0x0001e0 RW 0x8 > NOTE 0x0002a8 0x00000000000002a8 0x00000000000002a8 0x000024 > 0x000024 R 0x4 > NOTE 0x17dfc0 0x000000000017dfc0 0x000000000017dfc0 0x000020 > 0x000020 R 0x8 > TLS 0x17e8e0 0x000000000017f8e0 0x000000000017f8e0 0x000000 > 0x000020 R 0x8 > GNU_EH_FRAME 0x149558 0x0000000000149558 0x0000000000149558 0x007f04 > 0x007f04 R 0x4 > GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 > 0x000000 RW 0x10 > GNU_RELRO 0x17e8e0 0x000000000017f8e0 0x000000000017f8e0 0x00b720 > 0x00b720 R 0x1 > > Section to Segment mapping: > Segment Sections... > 00 [RO: .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version > .gnu.version_d .gnu.version_r .rela.dyn] > 01 [RO: .init .text .fini] > 02 [RO: .rodata .eh_frame_hdr .eh_frame .gcc_except_table > .note.gnu.property] > 03 [RELRO: .tbss .init_array .fini_array .data.rel.ro .dynamic .got] > .got.plt .data .bss > 04 [RELRO: .dynamic] > 05 [RO: .note.gnu.build-id] > 06 [RO: .note.gnu.property] > 07 [RELRO: .tbss] > 08 [RO: .eh_frame_hdr] > 09 > 10 [RELRO: .tbss .init_array .fini_array .data.rel.ro .dynamic .got]
So, Mark - any chance you could have a look at the above and give us your feedback? When I compare the actual mmap events with the LOAD segments, there are some similarities, but also some discrepancies. Note how the mmap sizes always differ from the FileSiz header value. And the offsets also sometimes mismatch, e.g. for the last segment / mmap event we get 0x17f8e0 in the header, but 0x17e000 in the mmap event...: LOAD 0x17e8e0 0x000000000017f8e0 0x000000000017f8e0 0x00b8b8 0x00ed60 RW 0x1000 0x7fac5ed8a000 to 0x7fac5ed97000, len = 0xd000, offset = 0x17e000 rw-p /usr/lib/libstdc++.so.6.0.25 I'm pretty confused here! -- Milian Wolff m...@milianw.de http://milianw.de
signature.asc
Description: This is a digitally signed message part.
