From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31895 invoked by alias); 18 Oct 2012 09:23:03 -0000 Received: (qmail 31884 invoked by uid 22791); 18 Oct 2012 09:23:01 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS,T_MANY_HDRS_LCASE 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 09:22:55 +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 <0MC300FWA0QO0I80@mailout2.w1.samsung.com> for gdb@sourceware.org; Thu, 18 Oct 2012 10:23:12 +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 <0MC3000QU0PQ1J50@eusync3.samsung.com> for gdb@sourceware.org; Thu, 18 Oct 2012 10:22:53 +0100 (BST) From: Michal Lesniewski To: gdb@sourceware.org Subject: Implementation of different software breakpoint kinds in gdb server Date: Thu, 18 Oct 2012 09:23:00 -0000 Message-id: <000001cdad12$1e2b1950$5a814bf0$%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/msg00077.txt.bz2 Hi All, I have been recently analyzing parts of GDB server code. I focused mainly on the ARM specific code and checked if it is possible to add tracepoint support for this architecture. I found out that there is a lot of work to do that but that's not the point. The main problem is the internal implementation of software breakpoints. The most general type of tracepoints are trap tracepoints (created using the trace command). These are implemented internally using software breakpoints. Software breakpoints are set by simply overwriting the instruction, at which the program should stop, by a trap instruction or illegal instruction. When the processor reaches the instruction, a exception occurs and gdbserver handles it. Now the problem is that gdbserver always uses the same trap/illegal instruction code. The functions in mem-break.c do not provide any way to allow using different kinds of trap instructions depending on some additional parameters. On most architectures this is OK, but on ARM there are two instruction sets - ARM (32 bit) and Thumb (mixed 16 and 32 bit). Depending on the instruction set used at a specific address, the trap instruction should be different. I was wondering if anybody was already considering to extend the code in mem-break.c to add support for different kinds of breakpoints. Best Regards, Michal Lesniewski