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