PR/2386 [2/2]: MinGW attach to process without an exec file

[Christopher Faylor]

On Sat, Dec 29, 2007 at 12:52:22PM +0000, Pedro Alves wrote:
> Joel Brobecker wrote:
>> I have a couple of questions, out of curiosity...
>
> Which prompted me to google a bit more :-)
>
> I guess I was trying too hard to not depend on psapi.dll.
> psapi.dll is available as part of the platform SDK, from MSFT,
> and since it is redistributable, as part of several
> applications, which means the chances it isn't
> there are slimm nowadays.  If it isn't there, like for
> instance the user is still on an NT4, it can be downloaded
> from MSFT.  "Platform SDK Redistributable: PSAPI for
> Windows NT" gets you there.
>
>>>   - looks in the Cygwin processes using cygwin_internal (CW_GETPINFO, 
>>> ...).
>>>     This is what's done currently, so Cygwin processes will be detected
>>>     like before.
>> If we are going to have some code that does this natively as suggested
>> below, why have some code that would work on cygwin only? Is the above
>> going to cover more cases (windows versions?) than the approach below?
>
> It will cover Cygwin processes on 9x, and the cases where psapi.dll
> isn't found.  I'll leave to Christopher to decide if it should
> be removed.
>
>>>   - If that fails, tries to get at the filename associated with the file
>>>     handle that the debug api gives us in the CREATE_PROCESS_DEBUG_EVENT.
>>>     Previously, it was just closed; we now store it in a global variable.
>>>     This relies on the internal NT name of the HANDLE, and it may change
>>>     in future releases, hence,
>
> I've stripped this part from the patch.
>
>  > Do you know when it wouldn't work?
> The name associated with the HANDLE is an internal, private NT detail
> which which happens to work in practice, in XP at least, but subject to
> change by MSFT.
>
>>>   - If that fails, GetModuleFileNameEx from psapi.dll is used.
>> Same here, if we know the conditions when this would or woudln't work,
>> a comment would be very helpful for future contributors.
>
> The function will always work for a process we're already debugging,
> provided dynamically loading psapi.dll works.
>
>
> The patch is now certainly much less invasive.  Chris, do you think
> it is on the right track now ?

On Fri, 28 Dec 2007 22:34:08 +0000 , Pedro Alves wrote:
>Not useful in this case, as the pid gdb holds is the native Windows pid.
>Hence current usage of cygwin_internal (CW_GETPINFO, ...).

I do find this less intrusive but I don't understand the above comment.
Did you actually try using /proc and found it wanting?  Finding a cygwin
exename should be as simple as just doing a readlink
("/proc/<pid>/exe").  I just tried this on a top-level process created
by cygwin and on the pid returned by typing "sleep 300&" in bash.  The
sleep process does have two pids associated with it due to the oddities
of the way that cygwin emulates exec but "ls -l /proc/<pid>/exe" showed
"/bin/sleep.exe" in each case.

For the rest of the code, have you investigated
"NtQuerySystemInformation"?  I don't know if it contains everything
needed but, despite what the Microsoft site says, it seems to have had a
stable interface for years and I don't see how Microsoft could change
the functionality without breaking lots of stuff.  I think it would be
better to adopt to probably nonexistent future API changes than it is
to rely on a DLL which may not be there.  I've always had a problem with
the psapi.h stuff for just the reasons that you mentioned.

We use NtQuerySystemInformation in cygwin to return the list of
processes.  See pinfo.cc.

For the Windows 9x case, I'd prefer if there was just a straightforward
error which indicated that what was being attempted is not available on
non-NT versions of Windows.

cgf