On 02/07/2020 08:44, Corinna Vinschen wrote:
On Jul 1 22:29, Jon Turney wrote:
This needs to be aligned with some changes to gdb to consume the dumps it
produces, so it's probably best to hold off applying this until it's more
obvious what's going to happen with those.
Random notes:
- objdump identifies the output of dumper on x86_64 as
'elf64-x86-64-cloudabi' (perhaps due to some over-eager sniffer).
- regions excluded from the dump aren't rounded up to page size, so we may
end up writing the excess into the dump.
- looking at the loaded modules and inspecting them to determine what memory
regions don't need to appear in the dump seems odd. I'm not sure we don't
just exclude MEMORY_BASIC_INFORMATION.Type == MEM_IMAGE regions (assuming
they get converted to MEM_PRIVATE regions if written when copy-on-write).
Unfortunately, that doesn't happen, and the region appears to stay
MEM_IMAGE, even if it's been modified.
I'm inclined to just dump MEM_IMAGE regions if they are writable
(although using the current protection isn't 100% correct, because it
may have been changed using VirtualProtect())
I suspect there's probably some undocumented MemoryInformationClass for
NtQueryVirtualMemory() that would let us determine if a region is
sharable or not, but ...
Could format_process_maps() in fhandler_process.cc be a role model here?
Thanks for pointing that out.
