Re: [PATCH] run > file for win32

[muller@cerbere.u-strasbg.fr]

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.