From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4137 invoked by alias); 30 Sep 2004 17:56:13 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 4121 invoked from network); 30 Sep 2004 17:56:11 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org with SMTP; 30 Sep 2004 17:56:11 -0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i8UI01QR024733 for ; Thu, 30 Sep 2004 11:00:01 -0700 (PDT) Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Thu, 30 Sep 2004 10:56:11 -0700 Received: from [17.201.22.240] (inghji.apple.com [17.201.22.240]) by relay3.apple.com (8.12.11/8.12.11) with ESMTP id i8UHu9E9012859; Thu, 30 Sep 2004 10:56:09 -0700 (PDT) In-Reply-To: <52BBA75459915749B68F93B604B636CD0D421E@neptune.TidalNetworks.net> References: <52BBA75459915749B68F93B604B636CD0D421E@neptune.TidalNetworks.net> Mime-Version: 1.0 (Apple Message framework v675) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <0470AA52-130A-11D9-85DF-000A958F4C44@apple.com> Cc: gdb@sources.redhat.com Content-Transfer-Encoding: quoted-printable From: Jim Ingham Subject: Re: breakpoint instruction isn't shown in disassemble or examine (x) commands? Date: Thu, 30 Sep 2004 17:56:00 -0000 To: Xinan Tang X-SW-Source: 2004-09/txt/msg00274.txt.bz2 "debug target" should show you all the reads & writes to a simulator.=20=20 If you are connecting to the target with gdb's remote protocol, you can=20 also use (gdb) set debug remote on to watch the gdb remote protocol communications. Do: (gdb) help set debug to see what sorts of debugging options are available for your gdb. Jim On Sep 30, 2004, at 10:42 AM, Xinan Tang wrote: > Hi > > =A0 If an ISA simulator is used, how could we do the same way as to the=20 > remote target in order to keep track of communication between GDB and=20 > the inferior ISA? > > Thanks > > --Xinan > > > -----Original Message----- > From: gdb-owner@sources.redhat.com on behalf of Jim Ingham > Sent: Thu 9/30/2004 10:30 AM > To: gdb@sources.redhat.com > Subject: Re: breakpoint instruction isn't shown in disassemble or=20 > examine (x) commands? > > gdb will always hide the breakpoint trap from you, and show you the > instruction that is actually going to be run when you get to that pc > instead.=A0 This is on purpose, it would be very confusing, and not at > all helpful, for folks to see trap instructions showing up in their > disassembly. > > Is there some reason, other than curiosity, the leads you to want to > see the trap there? > > If you are just curious, try running gdb with: > > (gdb) set debug target 1 > > You can see gdb copy out the actual instruction and lay down the traps, > and lots of other things you may or may not want to know about... > > Jim > > On Sep 29, 2004, at 11:36 PM, gdb-digest-help@sources.redhat.com wrote: > > > > > > > Hi, > > > > I am trying to understand the inner workings of a debugger and I=20 > found > > a gdb behaviour that puzzles me. > > > > I understand that if I set a software breakpoint (as opposed to > > an hw breakpoint), gdb will insert an architecture-dependent > > instruction > > in the .text section that will cause an exception, that will be=20 > handled > > by gdb. > > > > I am using gdb 6.1.1 on FreeBSD i386, so looking at the gdb source, > > the i386 has the breakpoint instruction 0xcc. > > > > I tought of doing something like (in various incantations): > > > > (gdb) disassemble foo > > (gdb) break foo > > (gdb) disassemble foo > > > > and was expecting of seeing the 0xcc instruction in the output of > > the second disassemble command; instead the output is the same > > as the first disassemble. Same results with the x command. > > It seems that gdb wants to "protect" me from seing that the=20 > executable > > is changed? > > > > Finally I came up with a function that scans the .text section of > > the same program (a sort of very naive debugger detector) > > and hex dumps it. I ran the same program with and without > > breakpoint and my scan function works as expected: when the=20 > breakpoint > > is > > set I see it in the hex dump. > > > > So somehow I have my sanity back, but the question remains: how > > can I see the breakpoint instruction from gdb itself? > > > > thanks > > marco > > -- > > panic("The moon has moved again."); > > > > >