[PATCH 0/8] Fix dumper for x86_64

[Jon Turney]

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.