From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13967 invoked by alias); 13 Dec 2004 22:57:54 -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 13773 invoked from network); 13 Dec 2004 22:57:45 -0000 Received: from unknown (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 13 Dec 2004 22:57:45 -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 iBDMvaBk020725; Mon, 13 Dec 2004 23:57:36 +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 iBDMvamS003473; Mon, 13 Dec 2004 23:57:36 +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 iBDMvafR003470; Mon, 13 Dec 2004 23:57:36 +0100 (CET) Date: Tue, 14 Dec 2004 02:06:00 -0000 Message-Id: <200412132257.iBDMvafR003470@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: cagney@gnu.org CC: drow@false.org, gdb-patches@sources.redhat.com In-reply-to: <41BE1743.8010902@gnu.org> (message from Andrew Cagney on Mon, 13 Dec 2004 17:27:15 -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> X-SW-Source: 2004-12/txt/msg00369.txt.bz2 Date: Mon, 13 Dec 2004 17:27:15 -0500 From: Andrew Cagney Mark Kettenis wrote: > Date: Mon, 13 Dec 2004 15:41:56 -0500 > From: Andrew Cagney > > Mark Kettenis wrote: > > > Can you rename saved_xfer_partial to super_xfer_partial_hack and add a > > FIXME. It should be calling super.xfer_partial but that's not available :-( > > > > Can you explain what you're hinting at here Andrew? What makes this > > specific saved_xfer_partial so different from the other saved_xxx > > instances that the patch introduces? > > Nothing? Changing those to be consistent with this would be a logical > next step. > > I suspect I don't see the big picture like you do, and I don't see why > you'd want a super.xfer_partial_hack. This construction isn't a hack > at all; it explicitly shows how the method is inherited. However, > super_xfer_partial is perhaps a better name than saved_xfer_partial. 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. > > 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. I simply think the way Daniel solved this, is the best way to do it. Mark