From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22887 invoked by alias); 2 Feb 2009 06:19:25 -0000 Received: (qmail 22879 invoked by uid 22791); 2 Feb 2009 06:19:24 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,FB_WORD1_END_DOLLAR,J_CHICKENPOX_53,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.187) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 02 Feb 2009 06:19:20 +0000 Received: by ti-out-0910.google.com with SMTP id d10so748518tib.12 for ; Sun, 01 Feb 2009 22:19:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.110.14.3 with SMTP id 3mr5978001tin.27.1233555556400; Sun, 01 Feb 2009 22:19:16 -0800 (PST) In-Reply-To: <20090201231819.A9FB61C7A19@localhost> References: <20090201231819.A9FB61C7A19@localhost> Date: Mon, 02 Feb 2009 06:19:00 -0000 Message-ID: Subject: Re: i386 int3 handling, running vs stepping From: teawater To: Doug Evans Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 2009-02/txt/msg00007.txt.bz2 Hi Doug, On Mon, Feb 2, 2009 at 07:18, Doug Evans wrote: > gdb is inconsistent in its handling of int3 instructions on x86. > > bash$ cat int3.S > .text > .global main > main: > nop > int3 > nop > hlt > > bash$ gcc -g -Wa,-g int3.S -o int3 > bash$ gdb int3 > (gdb) run > --> > Program received signal SIGTRAP, Trace/breakpoint trap. > main () at int3.S:6 > 6 nop > > Note that $pc is the insn AFTER the int3. > Question: Is this a bug? Should $pc point to the int3 instead? > [whether that's achieved with decr_pc_after_break or whatever > is a separate question] > I can argue either case, I don't have a preference per se. > This is not a bug. This because when x86 stop by breakpoint, the pc of it will point to next instruction. If this breakpoint is set by gdb, gdb will use adjust_pc_after_break set it to break address. Because this is not a gdb breakpoint, it stop at this address. And inferior stop at there because gdb think this is a random signal. If you set debug infrun 1, it will clear: infrun: stop_pc = 0x8048346 infrun: random signal 5 Program received signal SIGTRAP, Trace/breakpoint trap. infrun: stop_stepping > Trying things again, this time stepi'ing over the insn: > > bash$ gdb int3 > (gdb) start > [...] > Temporary breakpoint 1, main () at int3.S:4 > 4 nop > Current language: auto; currently asm > (gdb) si > 5 int3 > (gdb) si > 6 nop > (gdb) > > Note that int3 was stepping over without a SIGTRAP being generated. > I think this is because si return SIGTRAP too, gdb doesn't know there a random signal. Thanks, Hui