From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2020 invoked by alias); 14 Dec 2004 22:47:58 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 1938 invoked from network); 14 Dec 2004 22:47:47 -0000 Received: from unknown (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 14 Dec 2004 22:47:47 -0000 Received: from elgar.sibelius.xs4all.nl (elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id iBEMlOAj024120; Tue, 14 Dec 2004 23:47:24 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (localhost [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6) with ESMTP id iBEMlO2W000559; Tue, 14 Dec 2004 23:47:24 +0100 (CET) (envelope-from kettenis@elgar.sibelius.xs4all.nl) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6/Submit) id iBEMlFAT000554; Tue, 14 Dec 2004 23:47:15 +0100 (CET) Date: Wed, 15 Dec 2004 00:07:00 -0000 Message-Id: <200412142247.iBEMlFAT000554@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: cagney@gnu.org CC: drow@false.org, gdb-patches@sources.redhat.com In-reply-to: <41BE49F6.7060506@gnu.org> (message from Andrew Cagney on Mon, 13 Dec 2004 21:03:34 -0500) Subject: Re: [RFC] Use target vector inheritance for GNU/Linux References: <20041205184549.GA19814@nevyn.them.org> <41BC8521.9060107@gnu.org> <200412122107.iBCL7KEi011314@elgar.sibelius.xs4all.nl> <41BDFE94.9060401@gnu.org> <200412132134.iBDLYFHm002578@elgar.sibelius.xs4all.nl> <41BE1743.8010902@gnu.org> <200412132257.iBDMvafR003470@elgar.sibelius.xs4all.nl> <41BE49F6.7060506@gnu.org> X-SW-Source: 2004-12/txt/msg00375.txt.bz2 Date: Mon, 13 Dec 2004 21:03:34 -0500 From: Andrew Cagney > That is due to limitations in the current implementation, and not due to > issues with the Linux threading model (why you choose to blame GDB's > design flaws on the Linux threading model I don't know). The LWP layer > needs to always be active, and with that done the juggling you refer to > is eliminated. > > This has nothing to do with it. The problem is that > PtraceInferior.resume doesn't work correctly due to kernel bugs. We > need to fix that in GDB, and the best place to fix that is between > LinuxInferior and PtraceInferior. It's almost impossible to fix it in > something derived from LinuxInferior, since the implementation needs > access to linux-nat.c's internal state. Er, that is what a virtual function (to use C++ terminology) lets you do. Yup. FYI, this is the bug: /* 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. */ it turns out that to make this (and sig*.exp) work ment pushing through kernel changes - been there, done that. That code is now redundant (I tested my local GDB and that worked without it) and removing it would make things faster. I'm all for removing that hack when it's no longer necessary. However, before we decide that it isn't, we should make sure that we won't hurt existing users by doing so. IIRC you fixed this a couple of months ago. So there are probably still many people using kernels that aren't fixed. Was your bugfix backported and accepted in the Linux 2.4 kernel? Anyway, We once claimed that we support Linux 2.0 and up. This probably doesn't make sense anymore, but there are probably still many Linux 2.2 systems out there that people would like to use the latest GDB on. So I suspect it is still too early to remove this code. Meanwhile, it'd be great if you could add something to the comment that states the problem has been fixed. Please add the version(s) of the official Linux kernel where this was fixed, and when they were released. That will make it easier for us to decide when to remove this code. But even then, this is just one case of where platform-dependent "fixes" for the generic ptrace code are necessary. I think GDB should still allow for such bits of code in the future. Thanks, Mark