From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43522 invoked by alias); 30 Nov 2015 14:42:16 -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 43510 invoked by uid 89); 30 Nov 2015 14:42:16 -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,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; Mon, 30 Nov 2015 14:42:15 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id D41C168E23; Mon, 30 Nov 2015 14:42:13 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tAUEgCll029529; Mon, 30 Nov 2015 09:42:12 -0500 Message-ID: <565C6043.4040106@redhat.com> Date: Mon, 30 Nov 2015 14:42:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Yao Qi , gdb-patches@sourceware.org CC: simon.marchi@ericsson.com Subject: Re: Move threads out of jumppad without single step References: <86zixzvhj1.fsf@gmail.com> In-Reply-To: <86zixzvhj1.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-11/txt/msg00604.txt.bz2 On 11/27/2015 10:54 AM, Yao Qi wrote: > > Hi Pedro, > Can we move threads out of jumppad without using single step? I mean, > supposing GDBserver can compute the next PCs of the instruction on which > fast tracepoint is set, GDBserver can insert breakpoints at the next PCs > of the instruction fast tracepoint is set on, and resume the thread > which is in jumppad. > > In the recent discussion about ARM fast tracepoint support, I pointed > out that missing hardware single step may be a showstopper to ARM fast > tracepoint support, but Simon wants to convince me that we can have a > non-perfect fast tracepoint support on ARM with software single step. > After I think about the possible issues of using software single step, I > don't have any outcomes, but I wonder why do we need to single step > thread out of jumppad? Here is my understanding, in the jumppad, the > instructions are like, > > saved registers > spin lock > call gdb_collect > spin unlock > restore registers > <----- [1] > relocated instructions > jump back > > If PC is within the range above, GDBserver needs to move the thread > out. GDBserver can single step instructions one by one until PC is out > of this range, but we have an optimization here that GDBserver can > insert breakpoint and resume rather than single step one by one if PC > doesn't point to the relocated instructions yet [1]. Afterwards, > GDBserver will single step, but there aren't many instructions. Unless > I miss something, the code comments explain why do we move threads out > of jumppad, but they do *not* explain why do we move threads out of > jumppad in this way. IMO, the reason is that instructions before [1] > are sequentially executed (except call gdb_collect), but instructions > after [1] may not. We can safely insert breakpoint on [1], and thread > must hit the breakpoint. However, the original instruction on which the > fast tracepoint is set may be a branch instruction, so the relocated > instructions may jump back to the target address. Correct. But still, even if the relocated instruction does not jump back, we need to execute the last "jump back" instruction then. > At the moment we add > fast tracepoint support (for x86), we rely on hardware single step so > that we don't have to compute the next PCs (that is also the reason why > qRelocInsn packet was added). > > Now, the situation in GDBserver changed a little bit, as GDBserver will > be able to accurately compute the next PCs. Under this assumption, > GDBserver can compute the next PCs of the original instruction, and set > breakpoints there when threads are in jumppad. In this way, we don't > need to single step thread out jumppad at all for targets which support > software single step in GDBserver. I don't think we can determine the "next PCs" of the original instruction that easily even with the new software single-step work. E.g., if the instruction is an indirect branch, like "B r1", you need to know the contents of register r1 to tell where the branch will take you. But you can't compute offline what r1 will contain. That's why the code that computes the next PCs (the gdbarch_software_single_step implementations) assumes that the thread is currently stopped at the instruction that we want to compute the next PCs for. In the current arm_software_single_step implementation, you'll see the register context also used to e.g., handle the conditions in conditional execution instructions, based on state of registers and flags. You may be able to handle this by retrieving state from the saved registers buffer in the jump pad, similar to how gdb_collect cooks up a regcache, though unlike gdb_collect, you'll have to handle the case of the thread stopping midway through that register saving too (some registers already saved, some not yet). So I assume it's much simpler to just run to [1] as well, and then issue a normal software single-step when you get there. Also, not sure, but it's possible the stabilize threads machinery may need work to handle the "wrong threads" hitting that "out of jump pad" single-step breakpoint for another thread, and not have them start a new start over, but instead have them be locked immediately. Thanks, Pedro Alves