This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] run > file for win32
On Wed, Feb 20, 2002 at 10:58:11AM +0100, Pierre Muller wrote:
>At 03:39 16/02/2002 , vous avez ?crit:
>>I've just adapted some patches from Tak Ota to win32-nat.c.
>>Tak's patch didn't seem to be complete but the concept was so nice that
>>I took some time in the last few days and finished things.
>>The result is that you can use shell meta characters in gdb now, so
>>things like 'run < foo > bar' now work.
>>Since this is a departure from previous behavior, I turned this is off
>>by default. I added a 'set shell' command to control whether it is used
>after examining your patch, I think there is a mistake inside.
>Your patch uses a shell to start the debuggee and thus uses the flag
>DEBUG_PROCESS instead of DEBUG_ONLY_THIS_PROCESS.
>This means that you need to sort the events and only handle the events of the
>the second process created.
> First question:
> - is it sure that the shell will never call any process before
>running the executable that it has as argument?
No. This is just an initial implementation. I added hooks for doing it
better in the future. That's the reason this isn't on by default. I'm
sorry that I didn't make that clear.
>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.
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.
>But this variable is incremented each time a process is run.
> Starting value is -1
> shell starts value is 0
> debuggee starts value is 1 so the events are handled, here its OK.
>but if the debuggee starts another process then saw_create is incremented past 1 and
>no event is recorded anymore => the program is stuck....
>The following patch seems to overcome this bug.
>2002-01-08 Pierre Muller <firstname.lastname@example.org>
> * win32-nat.c (main_process_id): New variable. Used to only handle the
> events from the debuggee.
> (get_child_debug_event): Set main_process_id on the
> Use main_process_id to check if a given event should be handled
> by the debugger.