From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15560 invoked by alias); 31 Jan 2005 16:43:36 -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 15136 invoked from network); 31 Jan 2005 16:43:25 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 31 Jan 2005 16:43:25 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j0VGhOi5019866 for ; Mon, 31 Jan 2005 11:43:24 -0500 Received: from localhost.redhat.com (vpn50-70.rdu.redhat.com [172.16.50.70]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j0VGhOO15007; Mon, 31 Jan 2005 11:43:24 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 9E4887D79; Mon, 31 Jan 2005 11:42:47 -0500 (EST) Message-ID: <41FE6005.5050003@gnu.org> Date: Mon, 31 Jan 2005 16:43:00 -0000 From: Andrew Cagney User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) MIME-Version: 1.0 To: Matt Fyles Cc: gdb@sources.redhat.com Subject: Re: Stepping through code with breakpoints on adjacent address lines. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-01/txt/msg00163.txt.bz2 Matt Fyles wrote: > I just wanted to clear up the expected behavior when stepping code that has > breakpoints on adjacent address lines. > > In this simple example. > > 0x0 instruction A > 0x4 instruction B > 0x8 instruction C > > If I break on addresses 0x0, 0x4 and 0x8 with the break *(address) > functionality and then continue to 0x0 and step the other 2 instructions I > only ever see the breakpoint trigger on address 0x0. GDB steps to the next 2 > addresses but does not report a breakpoint at either location. Is this the > expected behavior. > > It looks from the source in infrun.c (handle_inferior_event()) that if the > trap_expected flag is set then it discards any breakpoint matching at the > current address. Smells like a broken edge case. Here's similar equally wierd behavior: (top-gdb) info break Num Type Disp Enb Address What 4 breakpoint keep y 0x1004e83c in main at /home/scratch/GDB/src/gdb/gdb.c:30 breakpoint already hit 1 time 5 breakpoint keep y 0x1004e83c in main at /home/scratch/GDB/src/gdb/gdb.c:31 breakpoint already hit 1 time 6 breakpoint keep y 0x1004e844 in main at /home/scratch/GDB/src/gdb/gdb.c:33 7 breakpoint keep y 0x1004e840 in main at /home/scratch/GDB/src/gdb/gdb.c:32 8 breakpoint keep y 0x1004e84c in main at /home/scratch/GDB/src/gdb/gdb.c:34 breakpoint already hit 1 time ((top-gdb) run Breakpoint 4, main (argc=0x1, argv=0x7ffff954) at /home/scratch/GDB/src/gdb/gdb.c:31 31 args.argc = argc; (top-gdb) s 32 args.argv = argv; (top-gdb) 33 args.use_windows = 0; (top-gdb) Breakpoint 8, main (argc=0x1, argv=0x7ffff954) at /home/scratch/GDB/src/gdb/gdb.c:34 34 args.interpreter_p = INTERP_CONSOLE; (top-gdb) info break Would you be able to come up with an automated testcase? Andrew