From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8083 invoked by alias); 29 Dec 2007 11:33:58 -0000 Received: (qmail 8075 invoked by uid 22791); 29 Dec 2007 11:33:58 -0000 X-Spam-Check-By: sourceware.org Received: from heller.inter.net.il (HELO heller.inter.net.il) (213.8.233.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 29 Dec 2007 11:33:50 +0000 Received: from HOME-C4E4A596F7 (IGLD-84-229-120-75.inter.net.il [84.229.120.75]) by heller.inter.net.il (MOS 3.7.3a-GA) with ESMTP id EML29085 (AUTH halo1); Sat, 29 Dec 2007 13:33:34 +0200 (IST) Date: Sat, 29 Dec 2007 11:41:00 -0000 Message-Id: From: Eli Zaretskii To: Pedro Alves CC: gdb-patches@sourceware.org In-reply-to: <477579E0.5010809@portugalmail.pt> (message from Pedro Alves on Fri, 28 Dec 2007 22:34:08 +0000) Subject: Re: PR/2386 [2/2]: MinGW attach to process without an exec file Reply-to: Eli Zaretskii References: <47744F9C.8040604@portugalmail.pt> <20071228013457.GB7602@ednor.casa.cgf.cx> <477579E0.5010809@portugalmail.pt> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-12/txt/msg00449.txt.bz2 > Date: Fri, 28 Dec 2007 22:34:08 +0000 > From: Pedro Alves > > 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. > > > [...] > 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. I'm not sure this version is significantly less intrusive than the original one, but that's for Chris to judge (FWIW, I didn't see much of intrusiveness in the original patch).