public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Yao Qi <qiyaoltc@gmail.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 03/17] Displaced stepping debug: fetch the right regcache
Date: Tue, 07 Apr 2015 14:12:00 -0000	[thread overview]
Message-ID: <5523E5B7.8070508@redhat.com> (raw)
In-Reply-To: <864mosxcts.fsf@gmail.com>

On 04/07/2015 02:55 PM, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
> 
>> gdb/ChangeLog:
>> 2015-04-01  Pedro Alves  <pedro@codesourcery.com>
>>
>> 	* infrun.c (resume) <displaced stepping debug output>: Get the
>> 	leader thread's regcache, not resume_ptid's.
> 
> Hi Pedro,
> From your change, I don't see why TP is the leader thread.

'resume' and 'target_resume' assume inferior_ptid is the "leader"
thread we want resumed -- TP is just the current thread
initialized at the top:

  struct thread_info *tp = inferior_thread ();

But e.g., if we're resuming with "set scheduler-locking off",
this:

  resume_ptid = user_visible_resume_ptid (user_step);

makes resume_ptid be a whole-process ptid, or
minus_one_ptid (all-threads).  In that case, the target_resume
backend implementation knows the thread that is the "leader" is
inferior_ptid, not the one passed as argument.

(though when we start a displaced step, resume_ptid is always
pointing at the current thread, never a wildcard ptid.)

>> @@ -2374,7 +2374,7 @@ resume (enum gdb_signal sig)
>>        && tp->control.trap_expected
>>        && use_displaced_stepping_now_p (gdbarch, sig))
>>      {
>> -      struct regcache *resume_regcache = get_thread_regcache (resume_ptid);
>> +      struct regcache *resume_regcache = get_thread_regcache (tp->ptid);
>>        struct gdbarch *resume_gdbarch = get_regcache_arch (resume_regcache);
>>        CORE_ADDR actual_pc = regcache_read_pc (resume_regcache);
> 
> If we get recache from TP, can we remove local variables
> resume_regcache, resume_gdbarch, actual_pc, and use regcache, gdbarch
> and pc we've got at the beginning of function resume instead?

Good point.  Indeed we should be able to.  The PC we got at the top would
be incorrect, given the thread's PC now points at the scratch pad,
but we already do:

	  /* Update pc to reflect the new address from which we will
	     execute instructions due to displaced stepping.  */
	  pc = regcache_read_pc (get_thread_regcache (inferior_ptid));

so the current PC's contents should work.  And that line could be:

  pc = regcache_read_pc (regcache);

too.

Thanks,
Pedro Alves

  reply	other threads:[~2015-04-07 14:12 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-01 22:14 [PATCH 00/17] All-stop on top of non-stop Pedro Alves
2015-04-01 22:14 ` [PATCH 01/17] Fix and test "checkpoint" in non-stop mode Pedro Alves
2015-04-01 22:14 ` [PATCH 17/17] native Linux: enable always non-stop by default Pedro Alves
2015-04-01 22:14 ` [PATCH 13/17] Fix signal-while-stepping-over-bp-other-thread.exp on targets always in non-stop Pedro Alves
2015-04-01 22:14 ` [PATCH 03/17] Displaced stepping debug: fetch the right regcache Pedro Alves
2015-04-07 10:47   ` Pedro Alves
2015-04-07 13:55   ` Yao Qi
2015-04-07 14:12     ` Pedro Alves [this message]
2015-04-01 22:14 ` [PATCH 10/17] Factor out code to re-resume stepped thread Pedro Alves
2015-04-01 22:14 ` [PATCH 09/17] Misc switch_back_to_stepped_thread cleanups Pedro Alves
2015-04-01 22:14 ` [PATCH 04/17] Change adjust_pc_after_break's prototype Pedro Alves
2015-04-01 22:14 ` [PATCH 02/17] PR13858 - Can't do displaced stepping with no symbols Pedro Alves
2015-04-01 22:14 ` [PATCH 08/17] Use keep_going in proceed and start_step_over too Pedro Alves
2015-04-01 22:24 ` [PATCH 07/17] Embed the pending step-over chain in thread_info objects Pedro Alves
2015-04-01 22:40 ` [PATCH 06/17] Make thread_still_needs_step_over consider stepping_over_watchpoint too Pedro Alves
2015-04-01 22:40 ` [PATCH 15/17] Fix step-over-trips-on-watchpoint.exp/step-over-lands-on-breakpoint.exp race Pedro Alves
2015-04-01 22:41 ` [PATCH 12/17] Implement all-stop on top of a target running non-stop mode Pedro Alves
2015-04-02 14:58   ` Eli Zaretskii
2015-04-07  9:51     ` Pedro Alves
2015-04-07 10:01       ` Eli Zaretskii
2015-04-07 10:11         ` Pedro Alves
2015-04-01 23:06 ` [PATCH 14/17] Fix interrupt-noterm.exp on targets always in non-stop Pedro Alves
2015-04-01 23:06 ` [PATCH 16/17] Disable displaced stepping if trying it fails Pedro Alves
2015-04-01 23:07 ` [PATCH 05/17] remote.c/all-stop: Implement TARGET_WAITKIND_NO_RESUMED and TARGET_WNOHANG Pedro Alves
2015-04-01 23:08 ` [PATCH 11/17] Teach non-stop to do in-line step-overs (stop all, step, restart) Pedro Alves
2015-04-07 12:52 ` [cancel] Re: [PATCH 00/17] All-stop on top of non-stop Pedro Alves

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=5523E5B7.8070508@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=qiyaoltc@gmail.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).