[PATCH 0/8] Fix dumper for x86_64
Sun Jul 5 16:49:43 GMT 2020
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.
More information about the Cygwin-patches