From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21731 invoked by alias); 30 Aug 2006 20:30:08 -0000 Received: (qmail 21722 invoked by uid 22791); 30 Aug 2006 20:30:07 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.palmsource.com (HELO mx2.palmsource.com) (12.7.175.14) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 30 Aug 2006 20:30:03 +0000 Received: from localhost (localhost [127.0.0.1]) by localhost.domain.tld (Postfix) with ESMTP id A6E55269CE; Wed, 30 Aug 2006 13:30:01 -0700 (PDT) Received: from mx2.palmsource.com ([127.0.0.1]) by localhost (mx2.palmsource.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01398-07-3; Wed, 30 Aug 2006 13:30:00 -0700 (PDT) Received: from ussunex01.palmsource.com (unknown [192.168.101.9]) by mx2.palmsource.com (Postfix) with ESMTP id 76CDE2697D; Wed, 30 Aug 2006 13:30:00 -0700 (PDT) Received: from 192.168.92.59 ([192.168.92.59]) by ussunex01.palmsource.com ([192.168.101.9]) via Exchange Front-End Server owa.palmsource.com ([10.0.20.17]) with Microsoft Exchange Server HTTP-DAV ; Wed, 30 Aug 2006 20:29:59 +0000 Received: from svmsnyderlnx by owa.palmsource.com; 30 Aug 2006 13:29:59 -0700 Subject: Re: Breakpoint Handling in GDB From: Michael Snyder To: "Veenu Verma (AS/EAB)" Cc: gdb@sourceware.org In-Reply-To: <3DAB128F75626444BB9DEA00DC59AD5501B1F7A1@esealmw104.eemea.ericsson.se> References: <3DAB128F75626444BB9DEA00DC59AD5501B1F7A1@esealmw104.eemea.ericsson.se> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 30 Aug 2006 20:30:00 -0000 Message-Id: <1156969799.24250.36.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-08/txt/msg00253.txt.bz2 On Wed, 2006-08-30 at 15:40 +0200, Veenu Verma (AS/EAB) wrote: > Hello > I was going through the gdb internals on software breakpoint handling > and have a question regarding that. > Gdb replaces the program instruction with a trap which means target does > not have any control over setting a bp. > What happens if the connection with the gdb breaks down ? > Does it mean that the illegal instruction won't be restored and the > application will crash ? In the general case, yes, that's what it means. > If that's the case, then how can it be handled ? The newer z0/Z0 remote commands will allow the target debug agent (eg. gdbserver) to handle the breakpoints. But if you're using the original method of breakpointing by writing trap instructions into target memory, then yes, you're vulnerable to the scenario that you describe. If you can't reboot the target, you MIGHT try re-connecting with gdb, and "fixing" the trap instructions by hand. Obviously this is "at your own risk". GDB does not have any built-in capability to help with the situation that you describe. However, I *have* used the following method: 1) If possible, get the locations of the breakpoints using gdb's "info break" command. 2) WITHOUT reconnecting to the target, load the target's executable file into gdb, and examine (and record) the contents of memory at those locations, eg. like this: (gdb) print /x *(unsigned int *) 0xabcdef 3) Now reconnect to the target, and modify those locations to match what's in the original binary file, eg.: (gdb) set *(unsigned int *) 0xabcdef = Again, YMMV, use at your own risk, operators are trained professionals etc. etc. Remember, there may be trap instructions that you don't know about, eg. if you were in the middle of a "next" or "finish" when you lost communication with the target.