From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 335 invoked by alias); 18 Oct 2012 12:01:38 -0000 Received: (qmail 32766 invoked by uid 22791); 18 Oct 2012 12:01:37 -0000 X-SWARE-Spam-Status: No, hits=-7.8 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Oct 2012 12:01:28 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q9IC0hFn026448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Oct 2012 08:01:22 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q9IC0fsf032503; Thu, 18 Oct 2012 08:00:42 -0400 Message-ID: <507FEF69.4030008@redhat.com> Date: Thu, 18 Oct 2012 12:01:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121009 Thunderbird/16.0 MIME-Version: 1.0 To: Michal Lesniewski CC: gdb@sourceware.org, "'Yao Qi'" Subject: Re: Implementation of different software breakpoint kinds in gdb server References: <000001cdad12$1e2b1950$5a814bf0$%lesniewski@samsung.com> <507FD526.5080604@redhat.com> <000101cdad25$e3eda550$abc8eff0$%lesniewski@samsung.com> In-Reply-To: <000101cdad25$e3eda550$abc8eff0$%lesniewski@samsung.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-10/txt/msg00083.txt.bz2 On 10/18/2012 12:44 PM, Michal Lesniewski wrote: > On 10/18/2012 12:09 PM, Pedro Alves wrote: >> Extending mem-break.c is not the big problem, IMO. > > But we'd probably have to change its interface a bit. So there would be also > changes needed in the architecture specific files like linux-*-low.c. > However, these changes would probably trivial for most architectures because > usually there is only one kind of trap instructions. Right. > >> The RSP already supports this, with the mode encoded in the "size" field > of the z0 packet. > > That's right, but the RSP does not support specifying kinds/sizes in the > QTDP packets, which are used for adding tracepoints, but that's a different > story. I added a enhancement request on bugzilla today, maybe there will be > some feedback: http://sourceware.org/bugzilla/show_bug.cgi?id=14740 Ah, didn't see it. Most of the people that would probably respond there are already in CC here. :-P Right. Although we've revamped the tracepoints support not that long ago (making it actually useful), the tracepoint packets are quite old, and that wasn't considered originally (even the encoding of mode/kind in the size/length field of z0 is recent). QTDP supports optional extensions, but it probably best to take a look at all the packets that are affected before deciding how to extended QTDP. > >> So we'd need to teach gdbserver to software single-step. Maybe it's > possible to tell offline all the possible destinations of an instruction, so > we could still leave that logic in gdb, but I suspect not. > > It's generally not possible. Of course, some instructions can never cause a > branch, so in these cases we could safely set the "reinsert-breakpoint" at > the next instruction. But some branch instructions read the branch > destination from a register. In this case we can only evaluate the next PC > value when the breakpoint is hit. > > Teaching gdbserver to single-step shouldn't be too hard. As you mentioned, > the logic is already there in gdb. I even found the code to do this in > arm-tdep.c (e.g. arm_get_next_pc). We could use it as a base to implement it > in gdbserver, but we would have some code duplication. It's not the next_pc bits per se, but the run control stuff that always gets tricky. Well, every time I think touching run control stuff in either gdb or gdbserver shouldn't be hard, I spend long whiles head banging. Maybe it's just me. :-) It'd be nice to avoid the duplication, though that might not be easy. >> I don't know whether the current kernel can already do all that for us? > (perf, uprobes, etc?) > > I tried uprobes, but it works in a different way. Instead of single > stepping, uprobes simulates (or emulates) the instruction, which was > replaced by the breakpoint. (It executes the instruction out-of-line and > jumps back to the original code. If this is not possible, it just looks at > the original instruction and modifies the registers and memory itself. This > solution has the advantage that it doesn't need to stop other threads while > one thread is single-stepping). Anyway, as far as I know uprobes does not > work on ARM yet. Thanks. Looking forward to all this. -- Pedro Alves