Re: [RFC] Use target vector inheritance for GNU/Linux

[Mark Kettenis <kettenis@gnu.org>]

   Date: Mon, 13 Dec 2004 17:27:15 -0500
   From: Andrew Cagney <cagney@gnu.org>

   Mark Kettenis wrote:
   >    Date: Mon, 13 Dec 2004 15:41:56 -0500
   >    From: Andrew Cagney <cagney@gnu.org>
   > 
   >    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