From: Michael Snyder <msnyder@cygnus.com>
To: "Peter.Schauer" <Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC] if (INNER_THAN (read_sp(), step_sp - 16))
Date: Wed, 27 Jun 2001 15:10:00 -0000 [thread overview]
Message-ID: <3B3A58EB.13087C2E@cygnus.com> (raw)
In-Reply-To: <200106230933.LAA24205@reisser.regent.e-technik.tu-muenchen.de>
"Peter.Schauer" wrote:
>
> Hellooooooo.
>
> This ugly hack is coming back to haunt me every other year, and if I'd
> know about a cleaner way to solve this, I'd already have done it long ago.
OK, would you review the attached change please?
It's meant to replace the (step_sp - 16) code by
using a state variable. I set the state variable
when we resume the target with a random signal while
singlestepping, and I clear it if we enter a trampoline.
This passes signals.exp, and does not create any new failures
on i386-linux.
Michael
2001-06-27 Michael Snyder <msnyder@redhat.com>
* infrun.c (struct execution_control_state): Add new field,
stepping_with_random_signal.
(init_execution_control_state): Initialize new field.
(handle_inferior_event): If stepping and passing a random
signal to the inferior, set 'stepping_with_random_signal'.
Use this state variable to detect hitting a breakpoint in
a signal handler without an intervening stop in sigtramp.
(check_sigtramp2): Clear stepping_with_random_signal if we
enter a signal trampoline.
(prepare_to_wait): Clear stepping_with_random_signal.
Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.39
diff -c -3 -p -r1.39 infrun.c
*** infrun.c 2001/06/26 00:26:42 1.39
--- infrun.c 2001/06/27 21:55:10
*************** struct execution_control_state
*** 1200,1205 ****
--- 1200,1206 ----
enum infwait_states infwait_state;
ptid_t waiton_ptid;
int wait_some_more;
+ int stepping_with_random_signal;
};
void init_execution_control_state (struct execution_control_state * ecs);
*************** fetch_inferior_event (void *client_data)
*** 1339,1344 ****
--- 1340,1347 ----
void
init_execution_control_state (struct execution_control_state *ecs)
{
+ /* FIXME: memset? We wouldn't have to keep adding inits for new fields. */
+ ecs->stepping_with_random_signal = 0;
/* ecs->another_trap? */
ecs->random_signal = 0;
ecs->remove_breakpoints_on_following_step = 0;
*************** handle_inferior_event (struct execution_
*** 2097,2114 ****
else
{
/* See if there is a breakpoint at the current PC. */
! stop_bpstat = bpstat_stop_status
(&stop_pc,
! /* Pass TRUE if our reason for stopping is something other
! than hitting a breakpoint. We do this by checking that
! 1) stepping is going on and 2) we didn't hit a breakpoint
! in a signal handler without an intervening stop in
! sigtramp, which is detected by a new stack pointer value
! below any usual function calling stack adjustments. */
! (currently_stepping (ecs)
! && !(step_range_end
! && INNER_THAN (read_sp (), (step_sp - 16))))
! );
/* Following in case break condition called a
function. */
stop_print_frame = 1;
--- 2100,2114 ----
else
{
/* See if there is a breakpoint at the current PC. */
! stop_bpstat = bpstat_stop_status
(&stop_pc,
! /* Pass TRUE if our reason for stopping is something other
! than hitting a breakpoint. We do this by checking that
! 1) stepping is going on and 2) we didn't hit a breakpoint
! in a signal handler without an intervening stop in
! sigtramp, which is detected by a state variable. */
! currently_stepping (ecs)
! && !ecs->stepping_with_random_signal);
/* Following in case break condition called a
function. */
stop_print_frame = 1;
*************** handle_inferior_event (struct execution_
*** 2257,2262 ****
--- 2257,2266 ----
platforms. --JimB, 20 May 1999 */
check_sigtramp2 (ecs);
keep_going (ecs);
+ /* Remember if we are stepping with a random signal. */
+ if (currently_stepping (ecs) &&
+ signal_stop[stop_signal] == 0)
+ ecs->stepping_with_random_signal = 1;
return;
}
*************** check_sigtramp2 (struct execution_contro
*** 2965,2970 ****
--- 2969,2975 ----
ecs->remove_breakpoints_on_following_step = 1;
ecs->another_trap = 1;
+ ecs->stepping_with_random_signal = 0;
}
}
*************** prepare_to_wait (struct execution_contro
*** 3232,3237 ****
--- 3237,3243 ----
registers_changed ();
ecs->waiton_ptid = pid_to_ptid (-1);
ecs->wp = &(ecs->ws);
+ ecs->stepping_with_random_signal = 0;
}
/* This is the old end of the while loop. Let everybody know we
want to wait for the inferior some more and get called again
From ac131313@cygnus.com Wed Jun 27 15:59:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFA: make D10V gdbarch functions static
Date: Wed, 27 Jun 2001 15:59:00 -0000
Message-id: <3B3A6556.1020300@cygnus.com>
References: <20010626184709.61B435E9CB@zwingli.cygnus.com>
X-SW-Source: 2001-06/msg00437.html
Content-length: 1135
> 2001-06-26 Jim Blandy <jimb@redhat.com>
>
> * d10v-tdep.c (10v_frame_chain_valid, d10v_use_struct_convention,
> d10v_breakpoint_from_pc, d10v_register_byte,
> d10v_register_raw_size, d10v_register_virtual_size,
> d10v_register_virtual_type, d10v_register_convertible,
> d10v_register_convert_to_virtual, d10v_register_convert_to_raw,
> d10v_make_daddr, d10v_make_iaddr, d10v_daddr_p, d10v_iaddr_p,
> d10v_convert_iaddr_to_raw, d10v_convert_daddr_to_raw,
> d10v_store_struct_return, d10v_store_return_value,
> d10v_extract_struct_value_address, d10v_frame_saved_pc,
> d10v_saved_pc_after_call, d10v_pop_frame, d10v_skip_prologue,
> d10v_frame_chain, d10v_frame_init_saved_regs,
> d10v_init_extra_frame_info, d10v_read_pc, d10v_write_pc,
> d10v_read_sp, d10v_write_sp, d10v_write_fp, d10v_read_fp,
> d10v_push_return_address, d10v_push_arguments,
> d10v_extract_return_value): Make these functions static.
I think everyone is pretty happy with the idea that static functions are
a good thing. BTW, if you're feeling daring, you could try deleting
config/d10v/tm-d10v.h - I'd even call that obvious :-)
Andrew
next prev parent reply other threads:[~2001-06-27 15:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3B2A97C7.52A839FD@cygnus.com>
[not found] ` <3B2A9EC8.7020106@cygnus.com>
2001-06-15 18:13 ` Michael Snyder
2001-06-16 9:42 ` Andrew Cagney
2001-06-23 2:33 ` Peter.Schauer
2001-06-25 18:04 ` Michael Snyder
2001-06-25 18:14 ` Michael Snyder
2001-06-27 15:10 ` Michael Snyder [this message]
2001-06-29 3:08 ` Peter.Schauer
2001-06-29 14:16 ` Michael Snyder
2001-07-01 5:10 ` Peter.Schauer
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=3B3A58EB.13087C2E@cygnus.com \
--to=msnyder@cygnus.com \
--cc=Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE \
--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