From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20144 invoked by alias); 20 Feb 2002 16:58:38 -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 20087 invoked from network); 20 Feb 2002 16:58:37 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by sources.redhat.com with SMTP; 20 Feb 2002 16:58:37 -0000 Received: from cgf.cipe.redhat.com (cgf.cipe.redhat.com [10.0.1.172]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id g1KGwal28870 for ; Wed, 20 Feb 2002 11:58:36 -0500 Received: (from cgf@localhost) by cgf.cipe.redhat.com (8.11.6/8.8.7) id g1KGweb28235 for gdb-patches@sources.redhat.com; Wed, 20 Feb 2002 11:58:40 -0500 Date: Wed, 20 Feb 2002 08:58:00 -0000 From: Christopher Faylor To: gdb-patches@sources.redhat.com Subject: Re: [PATCH] run > file for win32 Message-ID: <20020220165840.GJ26603@redhat.com> Mail-Followup-To: gdb-patches@sources.redhat.com References: <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 Content-Disposition: inline In-Reply-To: <4.2.0.58.20020220171640.0168c2b0@ics.u-strasbg.fr> User-Agent: Mutt/1.3.23.1i X-SW-Source: 2002-02/txt/msg00545.txt.bz2 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. >>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. 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. > -- 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. >-- 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. > 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. cgf