Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@gnat.com>
To: Andrew Cagney <ac131313@ges.redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] enable software single step on alpha-osf
Date: Fri, 16 Aug 2002 11:21:00 -0000	[thread overview]
Message-ID: <20020816182141.GJ906@gnat.com> (raw)
In-Reply-To: <3D5D323A.2030801@ges.redhat.com>

[-- Attachment #1: Type: text/plain, Size: 3370 bytes --]

> Did the re-ordering of that if statement get committed?
> This is wfi code so the smaller each change is the better.

[muttering something about too many things to do at the same time]

I tested (on Linux) and committed the attached patch. This is almost
the entire infrun.c change, except that I put the following change
on hold:

> >>The second part of the change is more tricky:
> >> +           stop_pc -= DECR_PC_AFTER_BREAK;

Concerning this particular change:

> >+           /* Readjust the stop_pc as it is off by DECR_PC_AFTER_BREAK
> >+              compared to the value it would have if the system stepping
> >+              capability was used. This allows the rest of the code in
> >+              this function to use this address without having to worry
> >+              whether software single step is in use or not.  */
> >+           stop_pc -= DECR_PC_AFTER_BREAK;
> >+           ecs->random_signal = 0;
> 
> Ok, I'm convinced that this is going in the right direction (and was 
> most likely the original intent of the code :-).  The more we can 
> localize DECR_PC_AFTER_BREAK (ie. extract it from bpstat_stop_status()) 
> the better! :-)
> 
> I this will be ok with some tweaks and a litte bit more experimentation.

Cool.

> I _think_ the above should be also writing the decremented stop_pc back 
> to the target.  This is what appears to happen else where.  It also 
> ensures that code that calls read_pc() instead of using stop_pc, gets a 
> consistent value.  However, there could be some sort of dragon lurking 
> here.  Can you please check this out?   The other possability is that 
> something is detecting that the PC wasn't written (status register) and 
> hence, assuming it should be decremented?  It might even be written by 
> resume().

It makes sense. I should be able to verify this change sometime soon.

> I think, the above code should also set a flag to indicate a ``software 
> single step trap'' occured.  That indication can then be passed down to 
> bpstat_stop_status() to so that it knows that this software single-step 
> trap is not a breakpoint and hence that the decr_pc_after_break doesn't 
> apply.  Off hand, a ``software_singlestep_p'' variable (||ed into 
> not_a_sw_breakpoint) or (better?) an extra enum trap_type (unknown_trap, 
> software_singlestep_trap) parameter explictly specifying the type of 
> trap that was identifed.

This needs to be investigated. So far, the not_a_sw_breakpoint seems
to be sufficient, but adding this flag would definitely make things
clearer, especially on the caller side.

May I suggest we treat this as a separate patch that would be applied
after all the issues in this RFA are dealt with?

> For the below, note that I've changed the variable name to 
> ``not_a_sw_breakpoint'' so you'll get a clash when merging.

Thanks.

So, to summarize: 

  1 - The change "+           stop_pc -= DECR_PC_AFTER_BREAK;" seems
      to be going in the right direction.

  2 - However I should hold this change for now because you think I should
      write the adjusted PC value back to the target, by adding something
      like "write_pc_pid (stop_pc, ecs->ptid)"

      I will verify the impact of such a change, and report.
    
  3 - Assuming we get all issues in this RFA resolved, then I will start
      looking at the addition of the software_singlestep flag.

-- 
Joel

[-- Attachment #2: infrun.c.diff --]
[-- Type: text/plain, Size: 1400 bytes --]

Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.64
diff -c -r1.64 infrun.c
*** infrun.c	24 Jul 2002 14:38:55 -0000	1.64
--- infrun.c	16 Aug 2002 17:55:05 -0000
***************
*** 1826,1835 ****
  
    if (stop_signal == TARGET_SIGNAL_TRAP)
      {
!       if (SOFTWARE_SINGLE_STEP_P () && singlestep_breakpoints_inserted_p)
! 	ecs->random_signal = 0;
!       else if (breakpoints_inserted
! 	       && breakpoint_here_p (stop_pc - DECR_PC_AFTER_BREAK))
  	{
  	  ecs->random_signal = 0;
  	  if (!breakpoint_thread_match (stop_pc - DECR_PC_AFTER_BREAK,
--- 1826,1836 ----
  
    if (stop_signal == TARGET_SIGNAL_TRAP)
      {
!       /* Check if a regular breakpoint has been hit before checking
!          for a potential single step breakpoint. Otherwise, GDB will
!          not see this breakpoint hit when stepping onto breakpoints.  */
!       if (breakpoints_inserted
!           && breakpoint_here_p (stop_pc - DECR_PC_AFTER_BREAK))
  	{
  	  ecs->random_signal = 0;
  	  if (!breakpoint_thread_match (stop_pc - DECR_PC_AFTER_BREAK,
***************
*** 1885,1890 ****
--- 1886,1895 ----
  		}
  	    }
  	}
+       else if (SOFTWARE_SINGLE_STEP_P () && singlestep_breakpoints_inserted_p)
+         {
+           ecs->random_signal = 0;
+         }
      }
    else
      ecs->random_signal = 1;

  reply	other threads:[~2002-08-16 18:21 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-18 13:55 Joel Brobecker
2002-07-22  4:19 ` Eli Zaretskii
2002-07-25 16:38 ` Andrew Cagney
2002-07-26 10:17   ` Jason R Thorpe
2002-07-31 10:28     ` Joel Brobecker
2002-08-04 16:42 ` Andrew Cagney
2002-08-05 11:49   ` Joel Brobecker
2002-08-05 20:01     ` Andrew Cagney
2002-08-16 10:11     ` Andrew Cagney
2002-08-16 11:21       ` Joel Brobecker [this message]
2002-08-16 12:11         ` Andrew Cagney
2002-08-16 12:26           ` Daniel Jacobowitz
2002-08-16 12:40             ` Kevin Buettner
2002-08-16 14:40               ` Peter.Schauer
2002-08-16 12:41             ` Andrew Cagney
2002-08-16 16:05         ` Joel Brobecker
2002-08-16 16:45           ` Andrew Cagney
2002-08-16 17:58             ` Joel Brobecker
2002-08-16 18:23               ` Andrew Cagney
2002-08-16 23:29                 ` Joel Brobecker
2002-08-20  8:55                   ` Joel Brobecker
2002-08-20 17:29                     ` Andrew Cagney
2002-08-20 19:14                       ` Daniel Jacobowitz
2002-08-21  7:01                         ` Joel Brobecker

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=20020816182141.GJ906@gnat.com \
    --to=brobecker@gnat.com \
    --cc=ac131313@ges.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