This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] run > file for win32
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,
>>>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
>>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,
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
>>>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
>I'd like to eventually record the name of the debugged process using
>>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
>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.