Christopher Faylor wrote:
> I'm not going to comment on the MinGW aspects of this other than to note
> that I think it is rather intrusive and I don't worrying about ancient
> Windows versions is a good idea.
> 

Then we should document it somewhere, that we don't support
Windows 9x anymore.  Maybe in the NEWS file ?

Can we reach a compromise here ?  I've removed the 9x support from this
patch.  With the changes inplace, win32_pid_to_exec_file

   - 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 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,
   - If that fails, GetModuleFileNameEx from psapi.dll is used.

The rest of the patch is just refactoring the psapi.dll loading
into its own function, not closing the file handle immediatelly, and
auxilary static functions to keep the code readable.

The enabling of the extra methods on Cygwin removes the need to
implement this TODO:
    "TODO: Also find native Windows processes using CW_GETPINFO_FULL."

... which is useful for attaching to apps built with
'gcc -mno-cygwin' with a Cygwin gdb.

> If you want to get the process name from a cygwin pid you just use the
> /proc interface.
> 

Not useful in this case, as the pid gdb holds is the native Windows pid.
Hence current usage of cygwin_internal (CW_GETPINFO, ...).

(I have a patch to clean up the ptid_t usage in win32-nat.c which
removes that "PID isn't a valid pid, unfortunately" limitation ... )

> cgf
> 

-- 
Pedro Alves