https://bugs.kde.org/show_bug.cgi?id=492663
--- Comment #2 from Paul Floyd <pjfl...@wanadoo.fr> ---
For the bad exe
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000025f4c 0x0000000000025f4c R 0x1000
LOAD 0x0000000000025f50 0x0000000000026f50 0x0000000000026f50
0x00000000000899b0 0x00000000000899b0 R E 0x1000
LOAD 0x00000000000af900 0x00000000000b1900 0x00000000000b1900
0x0000000000001700 0x0000000000001700 RW 0x1000
LOAD 0x00000000000b1000 0x00000000000b3000 0x00000000000b3000
0x0000000000000018 0x0000000000001fa8 RW 0x1000
So one RO one RX and two RW PT_LOADS. So I expect 3 or 4 calls to
VG_(di_notify_mmap) depending on whether the RW segments were merged or not.
First, the RO segment
--15892-- di_notify_mmap-0:
--15892-- di_notify_mmap-1: 0x108000-0x12dfff r--
--15892-- di_notify_mmap-2:
/home/paulf/scratch/vg_example/bug492663/testcase/firefox-bad
--15892-- di_notify_mmap-3: is_rx_map 0, is_rw_map 0, is_ro_map 1
--15892-- check_elf_and_get_rw_loads: ++*rw_load_count to 1 for
/home/paulf/scratch/vg_example/bug492663/testcase/firefox-bad p_vaddr 0xb1900
p_offset 719104, p_filesz 5888
--15892-- check_elf_and_get_rw_loads: ++*rw_load_count to 2 for
/home/paulf/scratch/vg_example/bug492663/testcase/firefox-bad p_vaddr 0xb3000
p_offset 724992, p_filesz 24
--15892-- di_notify_mmap-4: noting details in DebugInfo* at 0x100287C4D0
--15892-- di_notify_mmap-6: no dinfo loaded
/home/paulf/scratch/vg_example/bug492663/testcase/firefox-bad (no rx or no rw
mapping)
Next the RX segment
--15892-- di_notify_mmap-1: 0x12e000-0x1b8fff r-x
--15892-- di_notify_mmap-2:
/home/paulf/scratch/vg_example/bug492663/testcase/firefox-bad
--15892-- di_notify_mmap-3: is_rx_map 1, is_rw_map 0, is_ro_map 0
--15892-- check_elf_and_get_rw_loads: ++*rw_load_count to 1 for
/home/paulf/scratch/vg_example/bug492663/testcase/firefox-bad p_vaddr 0xb1900
p_offset 719104, p_filesz 5888
--15892-- check_elf_and_get_rw_loads: ++*rw_load_count to 2 for
/home/paulf/scratch/vg_example/bug492663/testcase/firefox-bad p_vaddr 0xb3000
p_offset 724992, p_filesz 24
--15892-- di_notify_mmap-4: noting details in DebugInfo* at 0x100287C4D0
--15892-- di_notify_mmap-6: no dinfo loaded
/home/paulf/scratch/vg_example/bug492663/testcase/firefox-bad (no rx or no rw
mapping)
Then there is one RW segment
--15892-- di_notify_mmap-0:
--15892-- di_notify_mmap-1: 0x1b9000-0x1bbfff rw-
--15892-- di_notify_mmap-2:
/home/paulf/scratch/vg_example/bug492663/testcase/firefox-bad
--15892-- di_notify_mmap-3: is_rx_map 0, is_rw_map 1, is_ro_map 0
--15892-- check_elf_and_get_rw_loads: ++*rw_load_count to 1 for
/home/paulf/scratch/vg_example/bug492663/testcase/firefox-bad p_vaddr 0xb1900
p_offset 719104, p_filesz 5888
--15892-- check_elf_and_get_rw_loads: ++*rw_load_count to 2 for
/home/paulf/scratch/vg_example/bug492663/testcase/firefox-bad p_vaddr 0xb3000
p_offset 724992, p_filesz 24
--15892-- di_notify_mmap-4: noting details in DebugInfo* at 0x100287C4D0
--15892-- di_notify_mmap-6: no dinfo loaded
/home/paulf/scratch/vg_example/bug492663/testcase/firefox-bad (no rx or no rw
mapping)
After a bit more debugging it looks like the problem is that 'firefox-bad' has
an object file type of ET_DYN (shared object file). readelf -e says
Type: DYN (Position-Independent Executable file)
This all makes sense now. We were only handling ET_EXEC (non-PIE exes).
One thing to do would be to change the condition to be
(ehdr_m.e_type == ET_EXEC || ehdr_m.e_type == ET_DYN) &&
(slightly more restrictive than the suggested patch).
I'm afraid that might break loading shared libraries. All of this horrible mess
is unnecessary for libraries since they get loaded by ld.so and I don't think
that the loader merges calls to mmap so there is always a 1 to 1 correlation
between the number of segments reported in the ELF header and the number of
calls to mmap that we see.
That just leaves the valgrind tool and the guest exe. The tool never has two RW
PT_LOADs - it's statically linked and the second RW PT_LOAD is used to split
data and bss from all the gubbins like the GOT.
I'll look to see if we can simply not merge the mmaps and segments for the
guest exe. I'm willing to sacrifice one NSegment to avoid all this complexity.
--
You are receiving this mail because:
You are watching all bug changes.
