Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261915AbUKVEGn (ORCPT ); Sun, 21 Nov 2004 23:06:43 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261919AbUKVEGn (ORCPT ); Sun, 21 Nov 2004 23:06:43 -0500 Received: from x35.xmailserver.org ([69.30.125.51]:32696 "EHLO x35.xmailserver.org") by vger.kernel.org with ESMTP id S261915AbUKVEGj (ORCPT ); Sun, 21 Nov 2004 23:06:39 -0500 X-AuthUser: davidel@xmailserver.org Date: Sun, 21 Nov 2004 20:06:35 -0800 (PST) From: Davide Libenzi X-X-Sender: davide@bigblue.dev.mdolabs.com To: Linus Torvalds cc: Andreas Schwab , Daniel Jacobowitz , Eric Pouech , Roland McGrath , Mike Hearn , Linux Kernel Mailing List , Andrew Morton , wine-devel Subject: Re: ptrace single-stepping change breaks Wine In-Reply-To: Message-ID: References: <200411152253.iAFMr8JL030601@magilla.sf.frob.com> <419E42B3.8070901@wanadoo.fr> <419E4A76.8020909@wanadoo.fr> <419E5A88.1050701@wanadoo.fr> <20041119212327.GA8121@nevyn.them.org> <20041120214915.GA6100@tesore.ph.cox.net> X-GPG-FINGRPRINT: CFAE 5BEE FD36 F65E E640 56FE 0974 BF23 270F 474E X-GPG-PUBLIC_KEY: http://www.xmailserver.org/davidel.asc MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2839 Lines: 79 On Sun, 21 Nov 2004, Linus Torvalds wrote: > On Mon, 22 Nov 2004, Andreas Schwab wrote: > > > > Linus Torvalds writes: > > > > > Now, try to "strace" it, or debug it with gdb, and see if you can repeat > > > the behaviour. > > > > You'll always have hard time repeating that under strace or gdb, since a > > debugger uses SIGTRAP for it's own purpose and does not pass it to the > > program. > > Sure. But "hard time" and "impossible" are two different things. > > It _should_ be perfectly easy to debug this, by using > > signal SIGTRAP > > instead of "continue" when you get a SIGTRAP that wasn't due to anything > you did. > > But try it. It doesn't work. Why? Because the kernel will have cleared TF > on the signal stack, so even when you do a "signal SIGTRAP", it will only > run the trap handler _once_, even though it should run it three times > (once for each instruction in between the "popfl"s. > > I do think this is actually a bug, although whether it's the bug that > causes problems for Wine is not clear at all. I'mm too lazy to build > and boot an older kernel, but I bet that on an older kernel you _can_ do > "signal SIGTRAP" three times, and it will work correctly. That would > indeed make this a regression. Hmmm ..., this is 2.4.27: [davide@bigblue davide]$ gcc -g -o zzzzzzzz zzzzzzzz.c [davide@bigblue davide]$ ./zzzzzzzz Copy protected: ok [davide@bigblue davide]$ gdb ./zzzzzzzz GNU gdb Red Hat Linux (5.3.90-0.20030710.41rh) Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) r Starting program: /home/davide/zzzzzzzz Program received signal SIGTRAP, Trace/breakpoint trap. 0x08048454 in main (argc=1, argv=0xbffff9c4) at zzzzzzzz.c:26 26 asm volatile("pushfl ; andl %0,(%%esp) ; popfl" (gdb) signal SIGTRAP Continuing with signal SIGTRAP. Program received signal SIGSEGV, Segmentation fault. 0x00000003 in ?? () (gdb) bt #0 0x00000003 in ?? () #1 0x0804846b in smc () at zzzzzzzz.c:32 #2 0x46649b7f in __libc_start_main () from /lib/i686/libc.so.6 #3 0x08048359 in _start () So it seems it did not work even before, the gdb-SIGTRAP stepping. In 2.6.8 I get a straight segfault just for running it. - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/