From: Andrew Cagney <ac131313@cygnus.com>
To: DJBARROW@de.ibm.com
Cc: gdb-patches@sourceware.cygnus.com, s390-patches@gnu.org,
schwidefsky@de.ibm.com, ARENZ@de.ibm.com
Subject: [patch] multi-arch ADDR_BITS_REMOVE; Was: New gdb 31 & 64 bit patches for S/390
Date: Fri, 15 Jun 2001 15:09:00 -0000 [thread overview]
Message-ID: <3B2A8794.5060904@cygnus.com> (raw)
In-Reply-To: <C1256A00.006F3FCE.00@d12mta09.de.ibm.com>
Hello,
(more s390 fallout) This patch multi-arches the ADDR_BITS_REMOVE
function. It uses a generic core_addr_identity() function as the default.
Andrew
From msnyder@cygnus.com Fri Jun 15 15:42:00 2001
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sources.redhat.com
Subject: Re: [RFC PATCH] normalize "thread hop" handling
Date: Fri, 15 Jun 2001 15:42:00 -0000
Message-id: <3B2A8F6A.4A6B0D9F@cygnus.com>
References: <3B2573B6.5E444250@cygnus.com>
X-SW-Source: 2001-06/msg00305.html
Content-length: 10029
Michael Snyder wrote:
>
> This patch normalizes the infrun handling of the "thread hop" event,
> when the wrong thread hits a thread-specific breakpoint and we need to
> singlestep that thread (only) before re-inserting breakpoints.
>
> The big benefit of this patch is that when we get the subsequent
> singlestep-trap, we process it normally in handle_inferior_event
> instead of just calling resume. This prevents bad things like
> failing to stop if the step takes us out of a stepping range.
>
> If nobody yells, I'll check it in in a few days.
Nobody yelled, so I'm committing this patch.
Michael
>
> ----------------------------------------------------------------------------------------------------
> 2001-06-11 Michael Snyder <msnyder@redhat.com>
>
> * infrun.c (context_switch): New function. Abstract the operation
> of saving and restoring infrun's state when switching threads.
> (handle_inferior_event): Normalize the handling of the 'thread hop'
> event (when the wrong thread hits a thread-specific breakpoint,
> and we need to solo-step that thread past the breakpoint).
> Call keep_going, instead of target_resume. Handle the subsequent
> singlestep-trap as a normal event instead of just resuming.
>
> Index: infrun.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/infrun.c,v
> retrieving revision 1.35
> diff -c -3 -p -r1.35 infrun.c
> *** infrun.c 2001/06/02 00:36:20 1.35
> --- infrun.c 2001/06/12 01:34:46
> *************** get_last_target_status(ptid_t *ptidp, st
> *** 1433,1438 ****
> --- 1433,1477 ----
> *status = target_last_waitstatus;
> }
>
> + /* Switch thread contexts, maintaining "infrun state". */
> +
> + static void
> + context_switch (struct execution_control_state *ecs)
> + {
> + /* Caution: it may happen that the new thread (or the old one!)
> + is not in the thread list. In this case we must not attempt
> + to "switch context", or we run the risk that our context may
> + be lost. This may happen as a result of the target module
> + mishandling thread creation. */
> +
> + if (in_thread_list (inferior_ptid) && in_thread_list (ecs->ptid))
> + { /* Perform infrun state context switch: */
> + /* Save infrun state for the old thread. */
> + save_infrun_state (inferior_ptid, prev_pc,
> + prev_func_start, prev_func_name,
> + trap_expected, step_resume_breakpoint,
> + through_sigtramp_breakpoint, step_range_start,
> + step_range_end, step_frame_address,
> + ecs->handling_longjmp, ecs->another_trap,
> + ecs->stepping_through_solib_after_catch,
> + ecs->stepping_through_solib_catchpoints,
> + ecs->stepping_through_sigtramp);
> +
> + /* Load infrun state for the new thread. */
> + load_infrun_state (ecs->ptid, &prev_pc,
> + &prev_func_start, &prev_func_name,
> + &trap_expected, &step_resume_breakpoint,
> + &through_sigtramp_breakpoint, &step_range_start,
> + &step_range_end, &step_frame_address,
> + &ecs->handling_longjmp, &ecs->another_trap,
> + &ecs->stepping_through_solib_after_catch,
> + &ecs->stepping_through_solib_catchpoints,
> + &ecs->stepping_through_sigtramp);
> + }
> + inferior_ptid = ecs->ptid;
> + }
> +
> +
> /* Given an execution control state that has been freshly filled in
> by an event from the inferior, figure out what it means and take
> appropriate action. */
> *************** handle_inferior_event (struct execution_
> *** 1451,1456 ****
> --- 1490,1500 ----
> {
> switch (ecs->infwait_state)
> {
> + case infwait_thread_hop_state:
> + /* Cancel the waiton_ptid. */
> + ecs->waiton_ptid = pid_to_ptid (-1);
> + /* Fall thru to the normal_state case. */
> +
> case infwait_normal_state:
> /* Since we've done a wait, we have a new event. Don't
> carry over any expectations about needing to step over a
> *************** handle_inferior_event (struct execution_
> *** 1467,1491 ****
> stepped_after_stopped_by_watchpoint = 0;
> break;
>
> - case infwait_thread_hop_state:
> - insert_breakpoints ();
> -
> - /* We need to restart all the threads now,
> - * unless we're running in scheduler-locked mode.
> - * Use currently_stepping to determine whether to
> - * step or continue.
> - */
> -
> - if (scheduler_mode == schedlock_on)
> - target_resume (ecs->ptid,
> - currently_stepping (ecs), TARGET_SIGNAL_0);
> - else
> - target_resume (RESUME_ALL,
> - currently_stepping (ecs), TARGET_SIGNAL_0);
> - ecs->infwait_state = infwait_normal_state;
> - prepare_to_wait (ecs);
> - return;
> -
> case infwait_nullified_state:
> break;
>
> --- 1511,1516 ----
> *************** handle_inferior_event (struct execution_
> *** 1888,1893 ****
> --- 1913,1919 ----
> * Use currently_stepping to determine whether to
> * step or continue.
> */
> + /* FIXME MVS: is there any reason not to call resume()? */
> if (scheduler_mode == schedlock_on)
> target_resume (ecs->ptid,
> currently_stepping (ecs),
> *************** handle_inferior_event (struct execution_
> *** 1901,1914 ****
> }
> else
> { /* Single step */
> ! target_resume (ecs->ptid, 1, TARGET_SIGNAL_0);
> ! /* FIXME: What if a signal arrives instead of the
> ! single-step happening? */
> !
> ecs->waiton_ptid = ecs->ptid;
> ecs->wp = &(ecs->ws);
> ecs->infwait_state = infwait_thread_hop_state;
> ! prepare_to_wait (ecs);
> return;
> }
> }
> --- 1927,1949 ----
> }
> else
> { /* Single step */
> ! breakpoints_inserted = 0;
> ! if (!ptid_equal (inferior_ptid, ecs->ptid))
> ! context_switch (ecs);
> ecs->waiton_ptid = ecs->ptid;
> ecs->wp = &(ecs->ws);
> + thread_step_needed = 1;
> + ecs->another_trap = 1;
> +
> + /* keep_stepping will call resume, and the
> + combination of "thread_step_needed" and
> + "ecs->another_trap" will cause resume to
> + solo-step the thread. The subsequent trap
> + event will be handled like any other singlestep
> + event. */
> +
> ecs->infwait_state = infwait_thread_hop_state;
> ! keep_going (ecs);
> return;
> }
> }
> *************** handle_inferior_event (struct execution_
> *** 1983,2022 ****
> /* It's a SIGTRAP or a signal we're interested in. Switch threads,
> and fall into the rest of wait_for_inferior(). */
>
> ! /* Caution: it may happen that the new thread (or the old one!)
> ! is not in the thread list. In this case we must not attempt
> ! to "switch context", or we run the risk that our context may
> ! be lost. This may happen as a result of the target module
> ! mishandling thread creation. */
> !
> ! if (in_thread_list (inferior_ptid) && in_thread_list (ecs->ptid))
> ! { /* Perform infrun state context switch: */
> ! /* Save infrun state for the old thread. */
> ! save_infrun_state (inferior_ptid, prev_pc,
> ! prev_func_start, prev_func_name,
> ! trap_expected, step_resume_breakpoint,
> ! through_sigtramp_breakpoint,
> ! step_range_start, step_range_end,
> ! step_frame_address, ecs->handling_longjmp,
> ! ecs->another_trap,
> ! ecs->stepping_through_solib_after_catch,
> ! ecs->stepping_through_solib_catchpoints,
> ! ecs->stepping_through_sigtramp);
> !
> ! /* Load infrun state for the new thread. */
> ! load_infrun_state (ecs->ptid, &prev_pc,
> ! &prev_func_start, &prev_func_name,
> ! &trap_expected, &step_resume_breakpoint,
> ! &through_sigtramp_breakpoint,
> ! &step_range_start, &step_range_end,
> ! &step_frame_address, &ecs->handling_longjmp,
> ! &ecs->another_trap,
> ! &ecs->stepping_through_solib_after_catch,
> ! &ecs->stepping_through_solib_catchpoints,
> ! &ecs->stepping_through_sigtramp);
> ! }
> !
> ! inferior_ptid = ecs->ptid;
>
> if (context_hook)
> context_hook (pid_to_thread_id (ecs->ptid));
> --- 2018,2024 ----
> /* It's a SIGTRAP or a signal we're interested in. Switch threads,
> and fall into the rest of wait_for_inferior(). */
>
> ! context_switch (ecs);
>
> if (context_hook)
> context_hook (pid_to_thread_id (ecs->ptid));
next prev parent reply other threads:[~2001-06-15 15:09 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-27 12:39 DJBARROW
2001-02-28 16:13 ` Nick Clifton
2001-06-15 8:15 ` s390 readline; Was: " Andrew Cagney
2001-06-15 10:27 ` Elena Zannoni
2001-06-15 16:26 ` Elena Zannoni
2001-06-15 9:53 ` Andrew Cagney
2001-06-15 11:46 ` Andreas Jaeger
2001-06-15 12:22 ` Andrew Cagney
2001-06-15 12:18 ` [patch] Add predicate for EXTRACT_STRUCT_VALUE_ADDRESS; Was: " Andrew Cagney
2001-06-15 23:56 ` Eli Zaretskii
2001-06-28 16:58 ` Andrew Cagney
2001-06-28 23:21 ` Eli Zaretskii
2001-06-15 15:09 ` Andrew Cagney [this message]
2001-06-15 16:09 ` [patch] multi-arch INIT_FRAME_PC*; " Andrew Cagney
2001-06-15 16:46 ` [patch] multi-arch CANNOT_^&*^*&_REGISTER(); " Andrew Cagney
2001-07-04 11:25 ` Andrew Cagney
2001-07-04 21:02 ` Andrew Cagney
2001-07-04 21:02 ` Andrew Cagney
2001-07-04 21:02 ` Andrew Cagney
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=3B2A8794.5060904@cygnus.com \
--to=ac131313@cygnus.com \
--cc=ARENZ@de.ibm.com \
--cc=DJBARROW@de.ibm.com \
--cc=gdb-patches@sourceware.cygnus.com \
--cc=s390-patches@gnu.org \
--cc=schwidefsky@de.ibm.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