From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9749 invoked by alias); 10 Dec 2007 23:17:21 -0000 Received: (qmail 9740 invoked by uid 22791); 10 Dec 2007 23:17:21 -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; Mon, 10 Dec 2007 23:17:14 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id CFD029801F for ; Mon, 10 Dec 2007 23:17:12 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id B0D6D9801D for ; Mon, 10 Dec 2007 23:17:12 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1J1rs7-00049w-Vq for gdb@sourceware.org; Mon, 10 Dec 2007 18:17:11 -0500 Date: Mon, 10 Dec 2007 23:17:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Subject: Re: Stepping off breakpoints in non-stop debugging mode Message-ID: <20071210231711.GA15675@caradoc.them.org> Mail-Followup-To: gdb@sourceware.org References: <20071208170359.GA8777@caradoc.them.org> 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/msg00073.txt.bz2 On Mon, Dec 10, 2007 at 03:05:01PM -0800, Jim Blandy wrote: > If signal handler trampolines can use sysenter / syscall, then we'll > need to recognize those, too. (Can they?) Yes, I think so. It depends on the kernel version and the vDSO variant it selected. Maybe not, though - there was some trouble about getting the right registers saved. > >> + /* 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. > > It does apply to GDB! You can write a statement that does "pushfl; > popl %0" and behaves differently depending on whether you continue > over it or step over it. You're not supposed to be able to do that. The kernel goes to great trouble to make sure that you can PTRACE_SINGLESTEP through such a sequence and have the same thing happen that would if no debugger was attached. My rule of thumb is that every time you have to explicitly modify TF, you're clobbering the program's state. Am I wrong? See is_setting_trap_flag in the kernel. Of course, it leaves the pushf case for debuggers to handle if they want to. Wine probably does. -- Daniel Jacobowitz CodeSourcery