Wed May 11 12:53:00 GMT 2011
On 11/05/2011 6:31 AM, Corinna Vinschen wrote:
> Hi Ryan,
> On May 11 01:27, Ryan Johnson wrote:
>> Hi all,
>> Please find attached three patches which extend the functionality of
> I applied youyr two first patches with a couple of changes:
> - Formatting: Setting of curly braces in class and method defintions,
> a lot of missing spaces, "int *foo" instead of "int* foo", stuff
> like that. Please compare what I checked in against your patch.
> That doesn't mean I always get it right myself, but basically that's
> how it should be.
Sorry... I did my best to match the surrounding code but didn't notice
the '* ' vs ' *' thing.
> - NT_MAX_PATH is the maximum size of a path including the trailing \0,
> so a buffer size of NT_MAX_PATH + 1 isn't required.
Good to know. Thanks.
> - I replaced the call to GetMappedFileNameEx with a call to
> NtQueryVirtualMemory (MemorySectionName). This avoids to add another
> dependency to psapi. I intend to get rid of them entirely, if
Nice. One issue: I tried backporting your change to my local tree, and
the compiler complains that PMEMORY_SECTION_NAME isn't defined; the
changelog says you updated ntdll.h to add it, but the online definition
in w32api was last updated 9 months ago by 'duda.' Did it perhaps slip
past the commit?
>> NOTE 1: I do not attempt to identify PEB, TEB, or thread stacks. The
>> first could be done easily enough, but the second and third require
>> venturing into undocumented/private Windows APIs.
> Go ahead! We certainly don't shy away from calls to
> NtQueryInformationProcess or NtQueryInformationThread.
Ah. I didn't realize this sort of thing was encouraged. The MSDN docs
about them are pretty gloomy.
The other things that discouraged me before were:
- the only obvious way to enumerate the threads in a process is to
create a snapshot using TH32CS_SNAPTHREAD, which enumerates all threads
in the system. This sounds expensive.
- it's not clear whether GetThreadContext returns a reasonable stack
pointer if the target thread is active at the time.
However, assuming the above do not bother folks, they should be pretty
straightforward to use. I won't have time to code this up in the
immediate future, though. My real goal was to make fork bearable on my
machine and that ended up sucking away all the time I had and then some...
>> NOTE 2: If desired, we could easily extend format_process_maps
>> further to report section names of mapped images (linux does this
>> for .so files), [...]
> Sorry if I'm dense, but isn't that exactly what GetMappedFileNameEx or
> NtQueryVirtualMemory (MemorySectionName) do? I also don't see any extra
> information for .so files in the Linux maps output. What detail am I
Interesting... the machine I used for reference a couple weeks ago was
running a really old debian, and for each allocation entry of a mapped
image it gave the corresponding section name (.text, .bss, .rdata, etc):
3463600000-346362c000 r-xp 00000000 08:01 2097238
346362c000-346382b000 ---p 0002c000 08:01 2097238
346382b000-346382c000 rw-p 0002b000 08:01 2097238
However, the machine was upgraded to a newer kernel this week and the
extra information no longer appears.
In any case, should somebody want to report section names within a
mapped image, that information can be had easily enough using the pefile
struct from my fork patches.
More information about the Cygwin-patches