From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11808 invoked by alias); 14 Dec 2004 02:06:02 -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 11766 invoked from network); 14 Dec 2004 02:05:54 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 14 Dec 2004 02:05:54 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iBE25mKs028432 for ; Mon, 13 Dec 2004 21:05:49 -0500 Received: from localhost.redhat.com (vpn50-64.rdu.redhat.com [172.16.50.64]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iBE25mr07870; Mon, 13 Dec 2004 21:05:48 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 6B77A3EF9; Mon, 13 Dec 2004 21:03:37 -0500 (EST) Message-ID: <41BE49F6.7060506@gnu.org> Date: Tue, 14 Dec 2004 15:41:00 -0000 From: Andrew Cagney User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) MIME-Version: 1.0 To: Mark Kettenis Cc: drow@false.org, gdb-patches@sources.redhat.com 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> In-Reply-To: <200412132257.iBDMvafR003470@elgar.sibelius.xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-12/txt/msg00370.txt.bz2 Mark Kettenis wrote: > What big picture? You're starting to make this sound like a conspiracy > ;-) If we had an O-O language we could call t.super.xfer_partial; we > don't so we hack around it using the global variable > super_xfer_partial_hack. > > As I noted later, we should fix things so that the global variable hack > isn't needed. But hey, in the mean time, lets fix it's name and move on. > > I don't agree it's a hack. It's the natural way to implement it in C. Using C to solve an O-O problem is a hack, but what ever. > > > No it isn't. At a very low level, all Linux ports are slightly > > > different. Most ports will need to adjust the generic ptrace target > > > before it can be inherited by the generic Linux target. In fact I > > > think that when the FETCH_INFERIOR_REGISTERS issue above is sorted > > > out, you'll see that *all* Linux ports will need to do this trick of > > > adjusting the ptrace target before passing it to linux_target(). > > > > > > (And yes, I'm fairly certain the method is still needed. While the > > > problem may have been fixed in recent kernels, there are many older > > > Linux kernels out there.) > > > > You're on the right track, however the inheritance structure that the C > > code is trying to mimic is: > > > > i386LinuxInferior IS-A LinuxInferior IS-A PtraceInferior > > > > Ah but that's not how the Linux-interfaces work (unless we drop > > support for multi-threading). LinuxInferior needs platform-dependent > > functionality that PtraceInferior doesn't (and shouldn't) provide. > > 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. 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. Andrew