This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: generic_prepare_to_proceed vs. Ctrl-C
- To: Jonathan Larmour <jlarmour at redhat dot com>
- Subject: Re: generic_prepare_to_proceed vs. Ctrl-C
- From: David Smith <dsmith at redhat dot com>
- Date: Wed, 23 May 2001 10:47:45 -0500
- CC: gdb-patches at sources dot redhat dot com
- Organization: Red Hat, Inc.
- References: <3B0AE715.17823A37@redhat.com>
Jonathan,
I see what you are trying to do, and I think it is a good idea.
Now let's get to the details of your patch. The main problem I have with
your patch is that it leaves that comment before switching the ptid's in an
odd state. I'd change it to something like "Switch back to WAIT_PID
thread.". Also, your change before the call to breakpoint_here_p() needs a
better comment explaining why we only return 1 if there is a breakpoint there.
One last thing. Your patch fixes the generic implementation of
PREPARE_TO_PROCEED, but it doesn't do anything for the 4 other
implementations of PREPARE_TO_PROCEED. These are located in: hppa-tdep.c,
lin-lwp.c, linux-thread.c, and m3-nat.c. At bare minimum you might add a
FIXME comment to each of the 4 other implementations describing what needs
doing. Of course if you have the time and are braver than I was, you could
try switching the Linux port to just use the generic version.
Jonathan Larmour wrote:
> David S's recently added generic_prepare_to_proceed() only takes account of
> stopping at a breakpoint and switching threads. It does not deal with
> stopping due to a Ctrl-C and switching threads. The below patch fixes this.
>
> Okay to check in?
>
> 2001-05-22 Jonathan Larmour <jlarmour@redhat.com>
>
> * arch-utils.c (generic_prepare_to_proceed): Allow for having
> stopped due to a Ctrl-C as well as breakpoints.
>
> Jifl
>
> Index: arch-utils.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/arch-utils.c,v
> retrieving revision 1.27
> diff -u -5 -p -r1.27 arch-utils.c
> --- arch-utils.c 2001/05/10 18:36:26 1.27
> +++ arch-utils.c 2001/05/22 22:19:29
> @@ -256,26 +256,26 @@ generic_prepare_to_proceed (int select_i
> struct target_waitstatus wait_status;
>
> /* Get the last target status returned by target_wait(). */
> get_last_target_status (&wait_ptid, &wait_status);
>
> - /* Make sure we were stopped at a breakpoint. */
> + /* Make sure we were stopped either at a breakpoint, or because
> + of a Ctrl-C. */
> if (wait_status.kind != TARGET_WAITKIND_STOPPED
> - || wait_status.value.sig != TARGET_SIGNAL_TRAP)
> + || (wait_status.value.sig != TARGET_SIGNAL_TRAP &&
> + wait_status.value.sig != TARGET_SIGNAL_INT))
> {
> return 0;
> }
>
> if (!ptid_equal (wait_ptid, minus_one_ptid)
> && !ptid_equal (inferior_ptid, wait_ptid))
> {
> /* Switched over from WAIT_PID. */
> CORE_ADDR wait_pc = read_pc_pid (wait_ptid);
>
> - /* Avoid switching where it wouldn't do any good, i.e. if both
> - threads are at the same breakpoint. */
> - if (wait_pc != read_pc () && breakpoint_here_p (wait_pc))
> + if (wait_pc != read_pc ())
> {
> if (select_it)
> {
> /* User hasn't deleted the breakpoint. Switch back to
> WAIT_PID and return non-zero. */
> @@ -286,12 +286,15 @@ generic_prepare_to_proceed (int select_i
> flush_cached_frames ();
> registers_changed ();
> stop_pc = wait_pc;
> select_frame (get_current_frame (), 0);
> }
> -
> - return 1;
> + /* Step over the breakpoint if there is one here. */
> + if (breakpoint_here_p (wait_pc))
> + {
> + return 1;
> + }
> }
> }
> return 0;
>
> }
>
>
--
David Smith
dsmith@redhat.com
Red Hat, Inc.
http://www.redhat.com
256.704.9222 (direct)
256.837.3839 (fax)