Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Peter Schauer <peterschauer@gmx.net>
To: palves@redhat.com (Pedro Alves)
Cc: qiyaoltc@gmail.com (Yao Qi),
	gdb-patches@sourceware.org,
	  uweigand@de.ibm.com (Ulrich Weigand)
Subject: Re: [rfc, spu] Don't call set_gdbarch_cannot_step_breakpoint in spu_gdbarch_init
Date: Wed, 01 Apr 2015 20:35:00 -0000	[thread overview]
Message-ID: <201504012035.t31KZ6xi004942@licht.localdomain> (raw)
In-Reply-To: <550C5D4B.9010808@redhat.com> from "Pedro Alves" at Mar 20, 2015 05:47:55 PM

> +Ulrich
> 
> Ulrich, any idea why cannot_step_breakpoint was ever needed?

This was needed for alpha OSF/1.

Back then it was the only architecture which would not ptrace step
over an inserted breakpoint, causing an infinite loop while trying
to single step over an inserted breakpoint.

The diff back then was

+ #ifdef CANNOT_STEP_BREAKPOINT
+   /* If the target doesn't support stepping over a breakpoint, simply
+      continue, we will then hit the breakpoint anyway.  */
+   if (step && breakpoints_inserted && breakpoint_here_p (read_pc ()))
+     step = 0;
+ #endif

I do not know if GDB ever tries to ptrace step over an inserted
breakpoint nowadays, sorry.
Meanwhile the alpha OSF/1 port is dead anyways...

> Yao's change makes sense to me.
> 
> Thanks,
> Pedro Alves
> 
> On 03/17/2015 02:52 PM, Yao Qi wrote:
> > From: Yao Qi <yao.qi@linaro.org>
> > 
> > Nowadays, in infrun.c:resume, the setting to 'step' variable is like:
> > 
> >   if (use_displaced_stepping (gdbarch)
> >       && tp->control.trap_expected
> >       && sig == GDB_SIGNAL_0
> >       && !current_inferior ()->waiting_for_vfork_done)
> >     {
> >     }
> >   /* Do we need to do it the hard way, w/temp breakpoints?  */
> >   else if (step)
> >     step = maybe_software_singlestep (gdbarch, pc); <-- [1]
> > 
> >   ...
> > 
> >   if (execution_direction != EXEC_REVERSE
> >       && step && breakpoint_inserted_here_p (aspace, pc))
> >     {
> >       ...
> >       if (gdbarch_cannot_step_breakpoint (gdbarch)) <-- [2]
> >         step = 0;
> >     }
> > 
> > spu doesn't have displaced stepping and uses software single step,
> > so 'step' is set to zero in [1], and [2] becomes unreachable as a
> > result.  So don't have to call set_gdbarch_cannot_step_breakpoint
> > in spu_gdbarch_init.
> > 
> > On the other hand, we either have hardware single step or software
> > single step, do we still need gdbarch method cannot_step_breakpoint?
> > CANNOT_STEP_BREAKPOINT was introduced in 1993 by commit
> > cef4c2e7a5f2d3426a8255f74b6c7f4e795fd9a4 for alpha OSF/1 native
> > support.
> > 
> > I don't have spu machine to test this patch.
> > 
> > gdb:
> > 
> > 2015-03-17  Yao Qi  <yao.qi@linaro.org>
> > 
> > 	* spu-tdep.c (spu_gdbarch_init): Don't call
> > 	set_gdbarch_cannot_step_breakpoint.
> > ---
> >  gdb/spu-tdep.c | 1 -
> >  1 file changed, 1 deletion(-)
> > 
> > diff --git a/gdb/spu-tdep.c b/gdb/spu-tdep.c
> > index 36ad312..870cf32 100644
> > --- a/gdb/spu-tdep.c
> > +++ b/gdb/spu-tdep.c
> > @@ -2794,7 +2794,6 @@ spu_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches)
> >    set_gdbarch_decr_pc_after_break (gdbarch, 4);
> >    set_gdbarch_breakpoint_from_pc (gdbarch, spu_breakpoint_from_pc);
> >    set_gdbarch_memory_remove_breakpoint (gdbarch, spu_memory_remove_breakpoint);
> > -  set_gdbarch_cannot_step_breakpoint (gdbarch, 1);
> >    set_gdbarch_software_single_step (gdbarch, spu_software_single_step);
> >    set_gdbarch_get_longjmp_target (gdbarch, spu_get_longjmp_target);
> >  

-- 
Peter Schauer			Peter.Schauer@mytum.de


  reply	other threads:[~2015-04-01 20:35 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-17 14:52 Yao Qi
2015-03-20 17:48 ` Pedro Alves
2015-04-01 20:35   ` Peter Schauer [this message]
2015-04-02  8:58     ` Pedro Alves
2015-04-02  9:09       ` Peter Schauer
2015-04-02  9:38         ` Pedro Alves
2015-04-02 12:44       ` Yao Qi
2015-04-07 12:45       ` Ulrich Weigand
2015-04-08 15:06         ` Yao Qi

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=201504012035.t31KZ6xi004942@licht.localdomain \
    --to=peterschauer@gmx.net \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    --cc=qiyaoltc@gmail.com \
    --cc=uweigand@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