Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Christopher Faylor <cgf@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] run > file for win32
Date: Wed, 20 Feb 2002 08:11:00 -0000	[thread overview]
Message-ID: <20020220161113.GH26603@redhat.com> (raw)
In-Reply-To: <4.2.0.58.20020220101817.00ace9a0@ics.u-strasbg.fr>

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
>>or not.
>
>Christopher, 
>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,
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.

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.

cgf

>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  <muller@ics.u-strasbg.fr>
>
>         * 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 
>         CREATE_PROCESS_DEBUG_EVENT. 
>         Use main_process_id to check if a given event should be handled 
>         by the debugger.


  reply	other threads:[~2002-02-20 16:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-16  2:03 Christopher Faylor
2002-02-20  1:58 ` Pierre Muller
2002-02-20  8:11   ` Christopher Faylor [this message]
2002-02-20  8:41     ` Pierre Muller
2002-02-20  8:58       ` Christopher Faylor
2002-02-20 10:42         ` muller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020220161113.GH26603@redhat.com \
    --to=cgf@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox