From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70071 invoked by alias); 7 Apr 2015 14:12:13 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 69899 invoked by uid 89); 7 Apr 2015 14:12:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 07 Apr 2015 14:12:11 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t37EC9Y0021594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 7 Apr 2015 10:12:09 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t37EC7qC031542; Tue, 7 Apr 2015 10:12:08 -0400 Message-ID: <5523E5B7.8070508@redhat.com> Date: Tue, 07 Apr 2015 14:12:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [PATCH 03/17] Displaced stepping debug: fetch the right regcache References: <1427926454-16431-1-git-send-email-palves@redhat.com> <1427926454-16431-4-git-send-email-palves@redhat.com> <864mosxcts.fsf@gmail.com> In-Reply-To: <864mosxcts.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-04/txt/msg00227.txt.bz2 On 04/07/2015 02:55 PM, Yao Qi wrote: > Pedro Alves writes: > >> gdb/ChangeLog: >> 2015-04-01 Pedro Alves >> >> * infrun.c (resume) : 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