From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6831 invoked by alias); 3 Feb 2009 01:26:41 -0000 Received: (qmail 6821 invoked by uid 22791); 3 Feb 2009 01:26:40 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 Feb 2009 01:26:35 +0000 Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id n131QWVr005308 for ; Tue, 3 Feb 2009 01:26:32 GMT Received: from rv-out-0708.google.com (rvfb17.prod.google.com [10.140.179.17]) by wpaz1.hot.corp.google.com with ESMTP id n131QTt6004251 for ; Mon, 2 Feb 2009 17:26:30 -0800 Received: by rv-out-0708.google.com with SMTP id b17so2017685rvf.38 for ; Mon, 02 Feb 2009 17:26:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.162.21 with SMTP id k21mr1729165rve.226.1233624389650; Mon, 02 Feb 2009 17:26:29 -0800 (PST) In-Reply-To: <20090202214915.GA4257@caradoc.them.org> References: <20090201231819.A9FB61C7A19@localhost> <20090201233251.GA27142@caradoc.them.org> <20090202042459.GA10080@caradoc.them.org> <20090202214915.GA4257@caradoc.them.org> Date: Tue, 03 Feb 2009 01:26:00 -0000 Message-ID: Subject: Re: i386 int3 handling, running vs stepping From: Doug Evans To: 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/msg00024.txt.bz2 On Mon, Feb 2, 2009 at 1:49 PM, Daniel Jacobowitz wrote: > On Mon, Feb 02, 2009 at 12:03:13PM -0800, Doug Evans wrote: >> On Sun, Feb 1, 2009 at 8:24 PM, Daniel Jacobowitz wrote: >> > On Sun, Feb 01, 2009 at 03:38:04PM -0800, Doug Evans wrote: >> >> I haven't looked into siginfo, but can gdb look at the insn? [akin to >> >> displaced stepping handling] >> > >> > I suppose, but I don't really see a point. >> >> Apologies, it's not clear what point you're referring to. >> >> I guess the issue is whether int3's in programs are supported by gdb, >> and by supported I mean users can rely on gdb flagging a SIGTRAP when >> they're executed. As you say, there are people who take advantage of >> this for hardwired breakpoints. > > Since it works today, and we know that people use it, I think we have > no choice but to consider it supported. > >> There are various situations where gdb itself will singlestep code >> (e.g., "step", "next", s/w watchpoints). Can users expect to see the >> SIGTRAP in these situations (and all others)? And if the program is >> being run by a script, can the script expect to see the SIGTRAP in all >> cases? > > That's certainly not the case today. If you want to make it work, and > add a couple of tests for it, I've no objection - it seems a plausible > thing to do. But I would prefer that any solution did not involve > reading the instruction at every step; that's quite slow, on a target > where we otherwise do not need to. Thanks. I don't know when I'd have time to get to this, mostly I wanted to make sure I understood why things are the way they are. For reference sake, while looking into something else I was reminded that the x86 linux port already looks at the insn being stepped. Heh. :-) [Without suggesting it's now a-priori ok to and add such reads to all ports.] [Things like trust-readonly can speed this up too.] static void i386_linux_resume (ptid_t ptid, int step, enum target_signal signal) { int pid = PIDGET (ptid); int request = PTRACE_CONT; if (step) { struct regcache *regcache = get_thread_regcache (pid_to_ptid (pid)); ULONGEST pc; gdb_byte buf[LINUX_SYSCALL_LEN]; request = PTRACE_SINGLESTEP; regcache_cooked_read_unsigned (regcache, gdbarch_pc_regnum (get_regcache_arch (regcache)), &pc); /* Returning from a signal trampoline is done by calling a special system call (sigreturn or rt_sigreturn, see i386-linux-tdep.c for more information). This system call restores the registers that were saved when the signal was raised, including %eflags. That means that single-stepping won't work. Instead, we'll have to modify the signal context that's about to be restored, and set the trace flag there. */ /* First check if PC is at a system call. */ if (target_read_memory (pc, buf, LINUX_SYSCALL_LEN) == 0 && memcmp (buf, linux_syscall, LINUX_SYSCALL_LEN) == 0) { ULONGEST syscall; regcache_cooked_read_unsigned (regcache, LINUX_SYSCALL_REGNUM, &syscall); /* Then check the system call number. */ if (syscall == SYS_sigreturn || syscall == SYS_rt_sigreturn) { ULONGEST sp, addr; unsigned long int eflags; regcache_cooked_read_unsigned (regcache, I386_ESP_REGNUM, &sp); if (syscall == SYS_rt_sigreturn) addr = read_memory_integer (sp + 8, 4) + 20; else addr = sp; /* Set the trace flag in the context that's about to be restored. */ addr += LINUX_SIGCONTEXT_EFLAGS_OFFSET; read_memory (addr, (gdb_byte *) &eflags, 4); eflags |= 0x0100; write_memory (addr, (gdb_byte *) &eflags, 4); } } } if (ptrace (request, pid, 0, target_signal_to_host (signal)) == -1) perror_with_name (("ptrace")); }