From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13589 invoked by alias); 2 May 2003 21:54:00 -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 13582 invoked from network); 2 May 2003 21:53:59 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by sources.redhat.com with SMTP; 2 May 2003 21:53:59 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id OAA08194; Fri, 2 May 2003 14:53:53 -0700 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma008178; Fri, 2 May 03 14:53:31 -0700 Received: from casey.transmeta.com (casey.transmeta.com [10.10.25.22]) by deepthought.transmeta.com (8.11.6/8.11.6) with ESMTP id h42LrZa18693; Fri, 2 May 2003 14:53:35 -0700 (PDT) Received: (from dje@localhost) by casey.transmeta.com (8.9.3/8.7.3) id OAA04417; Fri, 2 May 2003 14:53:34 -0700 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16050.59614.796437.738253@casey.transmeta.com> Date: Fri, 02 May 2003 21:54:00 -0000 To: "Liang, James" Cc: "'gdb@sources.redhat.com'" Subject: Breakpoint mechanism (breakpoint.c) In-Reply-To: <71251C7D5FB1D2119C8F0008C7A44ED103792077@es07snlnt.sandia.gov> References: <71251C7D5FB1D2119C8F0008C7A44ED103792077@es07snlnt.sandia.gov> X-SW-Source: 2003-05/txt/msg00021.txt.bz2 Liang, James writes: > Hello, > > I'm trying to port GDB and I can't quite understand what's happening with > the breakpoint mechanism in > breakpoint.c > > I've overwritten all of the set breakpoint modules in gdbarch.c, to go to > one of my functions that prints > "hello", but none of them are ever called. Whenever I try to set a > breakpoint, gdb just acts like the breakpoint > was successfully set. > > It looks like the work is setting the breakpoint is done in > create_breakpoints which calls set_raw_breakpoint. I just > don't see where it goes from there. As far as I can tell, it never calls > any architecture specific code or does anything except a few prints and > setting a few state variables. Nothing happens on the target side until execution is resumed. It's at that point that gdb calls the code to insert the breakpoint on the target. Grep for calls to insert_breakpoints.