From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78956 invoked by alias); 24 Jul 2015 11:52:58 -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 78941 invoked by uid 89); 24 Jul 2015 11:52:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS 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; Fri, 24 Jul 2015 11:52:52 +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 (Postfix) with ESMTPS id C38C18EA5D; Fri, 24 Jul 2015 11:52:50 +0000 (UTC) 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 t6OBqnVI009801; Fri, 24 Jul 2015 07:52:50 -0400 Message-ID: <55B22711.4080307@redhat.com> Date: Fri, 24 Jul 2015 11:52: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 7/8] Initialise target descrption after skipping extra traps for --wrapper References: <1437392126-29503-1-git-send-email-yao.qi@linaro.org> <1437392126-29503-8-git-send-email-yao.qi@linaro.org> <55B17806.2060000@redhat.com> <86bnf1hksj.fsf@gmail.com> In-Reply-To: <86bnf1hksj.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-07/txt/msg00695.txt.bz2 On 07/24/2015 12:11 PM, Yao Qi wrote: > Pedro Alves writes: > >> Instead of this whole code block, I think we should be able to skip >> the bits in the function that require accessing registers. E.g., >> this: >> >> /* Cancel actions that rely on GDB not changing the PC (e.g., the >> user used the "jump" command, or "set $pc = foo"). */ >> if (lwp->stop_pc != get_pc (lwp)) >> { >> /* Collecting 'while-stepping' actions doesn't make sense >> anymore. */ >> release_while_stepping_state_list (thread); >> } >> >> Could be guarded by: >> >> if (thread->while_stepping != NULL) >> >> And this: >> >> if (the_low_target.get_pc != NULL) >> { >> struct regcache *regcache = get_thread_regcache (current_thread, 1); >> >> lwp->stop_pc = (*the_low_target.get_pc) (regcache); >> >> if (debug_threads) >> { >> debug_printf (" %s from pc 0x%lx\n", step ? "step" : "continue", >> (long) lwp->stop_pc); >> } >> } >> >> could be guarded by: >> >> if (proc->tdesc == NULL) >> >> Did you try that? > > To make sure I understand you correctly, is the change below what you suggested? Yes. > If yes, I thought about this approach before, but I didn't try that > because I was worried that we should check every piece of code in > linux_resume_one_lwp_throw and its callees that don't access registers > when target description isn't initialised yet. Especially for > the_low_target.prepare_to_resume, the implementation of this hook should > be aware of that target description may not be available. Nowadays, > prepare_to_resume is only used to update HW debug registers, and > should be OK because GDBserver shouldn't update HW debug registers > before the inferior stops at the first instruction of the program. > However, in nat/x86-linux.c:lwp_debug_registers_changed, I saw such > comments > > struct arch_lwp_info *info = lwp_arch_private_info (lwp); > > /* NULL means either that this is the main thread still going > through the shell, or that no watchpoint has been set yet. > The debug registers are unchanged in either case. */ > > I was wondering all the implementations of prepare_to_resume of > different targets should be aware that "thread still going through the > shell"? Yes, I think they should. It's what the GDB side used to do already when that code was x86 gdb only (and hence that shell comment, which gdbserver doesn't use yet), and then other archs followed suit. "Going through the shell" is the exact same as going through the exec wrapper -- we're not interested in debugging the shell, and it may well have a different bitness/architecture of the target program we want to debug. In practice that hook's implementation should want to avoid work if some flag is not set, to avoid unnecessary ptrace syscalls and thus ends up not doing anything when going through the shell/exec-wrapper. > I'll test this patch on targets other than x86 (such as arm and > aarch64) and see if it causes fails. Thanks, Pedro Alves