Re: Cygwin 3.1.6
On 06/07/2020 20:50, Corinna Vinschen wrote: Hi guys, Do you have anything in the loop which should go into 3.1.6? No Given https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=bb96bd0, I'd like to release 3.1.6 this week.
Re: Cygwin 3.1.6
Corinna Vinschen wrote: Hi guys, Do you have anything in the loop which should go into 3.1.6? Nothing from me, thanks. ..mark
Re: Cygwin 3.1.6
On 7/6/2020 3:50 PM, Corinna Vinschen wrote: Hi guys, Do you have anything in the loop which should go into 3.1.6? Given https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=bb96bd0, I'd like to release 3.1.6 this week. I'm working on some FIFO fixes, but it could be another week until they're done and thoroughly tested. So I think you should go ahead, and the FIFO stuff can wait for 3.1.7. Ken
Cygwin 3.1.6
Hi guys, Do you have anything in the loop which should go into 3.1.6? Given https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=bb96bd0, I'd like to release 3.1.6 this week. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer
Re: [PATCH 0/8] Fix dumper for x86_64
On Jul 6 14:34, Jon Turney wrote: > On 06/07/2020 09:12, Corinna Vinschen wrote: > > 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). > > I came across [1], which seems to use some MemoryInformationClass values I > can't find any MSDN documentation on, but perhaps I'm getting lost. > > [1] > https://github.com/processhacker/processhacker/blob/master/phnt/include/ntmmapi.h#L87 Uh, sorry. I confused NtQueryVirtualMemory with just the MemoryBasicInformation class. Looking into the above, the MEMORY_REGION_INFORMATION struct looks pretty interesting but I doubt it helps... Corinna -- Corinna Vinschen Cygwin Maintainer
Re: [PATCH 0/8] Fix dumper for x86_64
On 06/07/2020 09:12, Corinna Vinschen wrote: 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). I came across [1], which seems to use some MemoryInformationClass values I can't find any MSDN documentation on, but perhaps I'm getting lost. [1] https://github.com/processhacker/processhacker/blob/master/phnt/include/ntmmapi.h#L87 What about the two protection fields in MEMORY_BASIC_INFORMATION? If something changed, Protect != AllocationProtect. Is that insufficient to handle your case? Unfortunately that doesn't seem to provide any additional information. The Windows loader seems to allocate all regions with EXWC protection, then change it to match the section. (Not that there are any guarantees about it's behaviour) I wasn't able to observe a region corresponding to an unmodified .data section with WC protection, which is somewhat confusing.
Re: [PATCH 0/8] Fix dumper for x86_64
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
