From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32410 invoked by alias); 30 Jan 2012 15:51:39 -0000 Received: (qmail 32388 invoked by uid 22791); 30 Jan 2012 15:51:36 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from imr3.ericy.com (HELO imr3.ericy.com) (198.24.6.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 30 Jan 2012 15:51:23 +0000 Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q0UFp069012617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jan 2012 09:51:02 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.142]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 30 Jan 2012 10:51:00 -0500 From: Marc Khouzam To: "'Yao Qi'" , "'Kevin Pouget'" CC: "'Robert Dewar'" , "'Jan Kratochvil'" , "'Xin Tong'" , "'gdb@sourceware.org'" Date: Mon, 30 Jan 2012 15:51:00 -0000 Subject: RE: software breakpoint in gdb Message-ID: References: <20120129165303.GA18465@host2.jankratochvil.net> <4F25EA26.8020901@adacore.com> <4F2635DA.3060805@codesourcery.com> In-Reply-To: <4F2635DA.3060805@codesourcery.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes 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-01/txt/msg00116.txt.bz2 > -----Original Message----- > From: gdb-owner@sourceware.org=20 > [mailto:gdb-owner@sourceware.org] On Behalf Of Yao Qi > Sent: Monday, January 30, 2012 1:17 AM > To: Kevin Pouget > Cc: Robert Dewar; Jan Kratochvil; Xin Tong; gdb@sourceware.org > Subject: Re: software breakpoint in gdb >=20 > On 01/30/2012 01:54 PM, Kevin Pouget wrote: > > I would be curious about why it would be "a disastrous mistake". > > Please correct me if I'm wrong in my understanding: >=20 > The real disaster is interrupt instruction may corrupt the following > instruction of breakpointed instruction, if interrupt instruction is > longer than breakpointed instruction. For example, >=20 > JMP L1: > ... > INSN1 (1-byte) > L1:INSN2 (2-byte) >=20 > Supposing the length of interrupt instruction is 2-byte, when setting > breakpoint on INSN1, the INSN2 is corrupted. If the program runs JMP > instruction to L1 directly, something wrong will be executed. In fact, I believe fast tracepoints in GDB had to deal with this very limitation. Fast tracepoints don't use an interrupt instruction (too slow) but instead use a jump instruction; that jump takes the execution to another location to execute the tracepoint directly in the program. Because we=20 cannot replace more than one instruction, fast tracepoints are only allowed on 5-byte instructions (actually, 4-byte instructions starting with GDB 7.4= ). Marc