From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23260 invoked by alias); 8 Dec 2007 17:04:11 -0000 Received: (qmail 23252 invoked by uid 22791); 8 Dec 2007 17:04:10 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 08 Dec 2007 17:04:02 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id CC6A4980A7 for ; Sat, 8 Dec 2007 17:04:00 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id A98A3980A5 for ; Sat, 8 Dec 2007 17:04:00 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1J135r-0002XL-VN for gdb@sourceware.org; Sat, 08 Dec 2007 12:03:59 -0500 Date: Sat, 08 Dec 2007 17:04:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Subject: Re: Stepping off breakpoints in non-stop debugging mode Message-ID: <20071208170359.GA8777@caradoc.them.org> Mail-Followup-To: gdb@sourceware.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.15 (2007-04-09) 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: 2007-12/txt/msg00066.txt.bz2 On Sat, Dec 08, 2007 at 01:23:38AM -0800, Jim Blandy wrote: > - The current implementation of gdbarch_displaced_step_location is > pretty questionable, but I'm not sure where else would be better. Ditto. This may do. > - It seems that it is never necessary to have more than one thread > doing displaced stepping at a time --- or else the assert in > displaced_step_prepare would trigger --- but I don't see why this > should be so. Isn't this because you haven't been testing combined with Vladimir's leave-breakpoints-inserted code? resume is still going to force only the current thread to resume and wait, so the single step will finish before anything else gets a chance to hit a new breakpoint. Combine those two patches, this will start happening. Add non-stop debugging and it will happen even more. > +static int > +i386_syscall_p (gdb_byte *insn, ULONGEST *lengthp) > +{ > + if (insn[0] == 0xcd) > + { > + *lengthp = 2; > + return 1; > + } > + > + return 0; > +} That's int, I assume. May need sysenter / syscall, depending on the platform. > + /* The list of issues to contend with here is taken from > + resume_execution in arch/i386/kernel/kprobes.c, Linux 2.6.20. > + Yay for Free Software! */ > + > + /* Clear the TF flag in EFLAGS, which will always be set. */ > + { > + ULONGEST eflags; > + regcache_cooked_read_unsigned (regs, I386_EFLAGS_REGNUM, &eflags); > + eflags &= ~I386_TF_MASK; > + regcache_cooked_write_unsigned (regs, I386_EFLAGS_REGNUM, eflags); > + } Does this manual adjustment of TF apply to GDB? The kernel is supposed to handle TF entirely inside ptrace, and expose the original %eflags to GDB (though various kernel versions have gotten this wrong, I believe it is right at last). So if TF is set here, that means the program being debugged had TF set already. > + /* Relocate the %eip, if necessary. */ > + > + /* In the case of absolute or indirect jump or call instructions, or > + a return instruction, the new %eip needs no relocation. */ > + if (i386_absolute_jmp_p (insn) > + || i386_absolute_call_p (insn) > + || i386_ret_p (insn)) > + ; > + > + /* Except in the case of absolute or indirect jump or call > + instructions, or a return instruction, the new eip is relative to > + the displaced instruction; make it relative. Well, signal > + handler returns don't need relocation either, but we use the > + value of %eip to recognize those; see below. */ > + if (! i386_absolute_jmp_p (insn) > + && ! i386_absolute_call_p (insn) > + && ! i386_ret_p (insn)) These two if statements look quite strange together. -- Daniel Jacobowitz CodeSourcery