Hi Milian, On Wed, Oct 17, 2018 at 04:52:42PM +0200, Milian Wolff wrote: > On Montag, 15. Oktober 2018 23:06:07 CEST Milian Wolff wrote: > > On Montag, 15. Oktober 2018 23:04:52 CEST Mark Wielaard wrote: > > > 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?
Sorry, I haven't yet looked at this deeply. But some quick comments. The mmap events do seem to correspond to the PT_LOAD segments. At least the offsets are. Why the second on is mmapped twice I don't know. The difference in length for the last 3 seems to be that the mmaps are aligned up (0x1000, 4K, page size) > 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! I think the differences can be explained by the fact that mmap will use aligned offsets and length. In theory libdwfl just needs to see one mmap even and should then be able to use the phdrs PT_LOAD headers to see how the whole file is mmapped into memory. Maybe something goes wrong there. And reporting multiple events for the same file might confuse things. Cheers, Mark
