From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10041 invoked by alias); 20 Feb 2002 18:42:04 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 9814 invoked from network); 20 Feb 2002 18:41:52 -0000 Received: from unknown (HELO factorix.sdv.fr) (194.206.196.2) by sources.redhat.com with SMTP; 20 Feb 2002 18:41:52 -0000 Received: from ordimaison (ip-76-34.evc.net [212.95.76.34]) by factorix.sdv.fr (8.11.4/8.11.4) with SMTP id g1KIfol16265 for ; Wed, 20 Feb 2002 19:41:50 +0100 Message-Id: <3.0.6.32.20020220194315.0135e8b0@ics.u-strasbg.fr> X-Sender: muller@ics.u-strasbg.fr X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 20 Feb 2002 10:42:00 -0000 To: gdb-patches@sources.redhat.com From: muller@cerbere.u-strasbg.fr Subject: Re: [PATCH] run > file for win32 In-Reply-To: <20020220165840.GJ26603@redhat.com> References: <4.2.0.58.20020220171640.0168c2b0@ics.u-strasbg.fr> <4.2.0.58.20020220101817.00ace9a0@ics.u-strasbg.fr> <20020216023944.GA22542@redhat.com> <4.2.0.58.20020220101817.00ace9a0@ics.u-strasbg.fr> <4.2.0.58.20020220171640.0168c2b0@ics.u-strasbg.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SW-Source: 2002-02/txt/msg00560.txt.bz2 At 11:58 20/02/02 -0500, Christopher Faylor wrote: >On Wed, Feb 20, 2002 at 05:40:24PM +0100, Pierre Muller wrote: >> >>> >To sort the events and only handles those of the process that you want >>> >to debug you use saw_create variable. >>> >>>IMO, the right way to handle this is to inspect the name of each process >>>as it is created. That presents some interesting difficulties, however. >>>It means that gdb has to understand how the shell will find the executable, >>>however. >>> >>>Alternatively, gdb could detect the transition from shell -> program where >>>the pid stays the same. Hmm. I think that would be the most foolproof. >> >>But that is not the case... the windows pid does change when you pass from the >>shell to the debuggee. My patch is even based on that change. > >I was talking about the cygwin pid. It doesn't change across an exec, just like >UNIX. OK, but it must also work for non-cygwin executables. >>>I'll try to come up with some kind of solution to this that uses your method >>>plus the above. It will probably take a couple of days, though. >> >>As the win32 API clearly says that the lpImageName field of the >>CREATE_PROCESS_DEBUG_EVENT can be null, this is not an option. > >We have methods for dealing with this, though. They aren't implemented >for this case but they are for the situation where we're attaching a >process. > >I'd like to eventually record the name of the debugged process using >these methods. > >>May I suggest using GetFileInformationByHandle function? >> >>If you open the file in the child_create_inferior function and leave it >>open until the program is killed or exits, > >The problem is, as I mentioned, we don't know what the file is named. >The fact that you are debugging 'foo.exe' doesn't mean that the actual >file is ./foo.exe. I am not sure this is true, when I tried it, the name of the executable was always a fully qualified name, it probably expanded before. Its already so if you type 'info file'. >Detecting when windows pid changes and the cygwin pid stays the same >seems to be a foolproof method for dealing with this. > >>-- I don't know if this is a problem with my configuration, but the >>getenv("SHELL") returns NULL in _initialize_inftarg while I do have >>SHELL=/bin/bash in the bash that I use as shell... > >If you are saying that getenv isn't working, then there is certainly >a problem somewhere. I will try to investigatee that a little. >> -- This reminds me of one more question: >>do all shells accept "exec" command and -c option ? > >If they don't then the user will have to use the "set shell off" option. >fork-child.c seems to assume that -c is universal, however. But maybe without 'exec'? >>-- We need to be very careful about the different handles that I given >>by the different events, failing to close some might result in problems >>later. > >I kinda thought I was careful about this. I didn't look closely. Its probably perfectly allright if you already tought about this possible problem. >> Finally, wouldn't it be wise to set the default value of useshell to 0 >>until this problem is fixed? >>Currently the variable is set to 1 in _initialize_inftarg >>if a shell is found. > >Actually, I'm going to turn it off by default even when this is fixed. Its probably the wisest solution. But I just committed ingdb.texinfo that its on by default, so don't forget to change that also.