From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21807 invoked by alias); 18 Oct 2012 11:44:23 -0000 Received: (qmail 21796 invoked by uid 22791); 18 Oct 2012 11:44:22 -0000 X-SWARE-Spam-Status: No, hits=-7.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mailout2.w1.samsung.com (HELO mailout2.w1.samsung.com) (210.118.77.12) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Oct 2012 11:44:17 +0000 Received: from eusync3.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) by mailout2.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0MC3004CU7AASS90@mailout2.w1.samsung.com> for gdb@sourceware.org; Thu, 18 Oct 2012 12:44:34 +0100 (BST) Received: from amdn392 ([106.116.61.216]) by eusync3.samsung.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPA id <0MC300B5J79NL4A0@eusync3.samsung.com> for gdb@sourceware.org; Thu, 18 Oct 2012 12:44:15 +0100 (BST) From: Michal Lesniewski To: 'Pedro Alves' Cc: gdb@sourceware.org, 'Yao Qi' References: <000001cdad12$1e2b1950$5a814bf0$%lesniewski@samsung.com> <507FD526.5080604@redhat.com> In-reply-to: <507FD526.5080604@redhat.com> Subject: RE: Implementation of different software breakpoint kinds in gdb server Date: Thu, 18 Oct 2012 11:44:00 -0000 Message-id: <000101cdad25$e3eda550$abc8eff0$%lesniewski@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-TM-AS-MML: No 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/msg00082.txt.bz2 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. > 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 > 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. > 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. Michal Lesniewski