[PATCH 0/8] Fix dumper for x86_64

[Corinna Vinschen]

On Jul  5 17:49, Jon Turney wrote:
> 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 ...

Surprisingly, there's nothing undocumented in NtQueryVirtualMemory and
the API is fully exposed by VirtualQuery(Ex).

What about the two protection fields in MEMORY_BASIC_INFORMATION?  If
something changed, Protect != AllocationProtect.  Is that insufficient
to handle your case?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer