Re: [PATCH] run > file for win32

[Christopher Faylor <cgf at redhat dot com>]

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