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

[Andrew Cagney <cagney at gnu dot 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.

>    > 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.

However, attempting that is clearly a follow-on (and one that Daniel 
wizely avoided), hence my suggestion to add a function as the interum.

Andrew

>    with the i386LinuxInferior.resume method overriding LinuxInferior.resume 
>    (which overrid PtraceInferior.resume); and not:
>
> But having i386LinuxInferior override LinuxInferior.resume really
> sucks because then it too has to do this insane dance of fiddling with
> LWPs because of the braindamaged Linux threading model.
>
>    LinuxInferior IS-A i386LinuxInferior IS-A PtraceInferior
>
> This reflects reality better, although it might even be:
>
> i386LinuxInferior IS-A LinuxInferior IS-A i386LinuxPtraceInferior
>   IS-A PtraceInferior
>
> But that breaks some OO rules of course.
>
>    That the current inferior code doesn't facilitate this is a recognized 
>    problem, but not one that we should get hung-up over.  Hence my 
>    suggestion of deprecated_set_super_linux_resume as a workaround until 
>    that is fixed.
>
> It's not a problem with the current inferior code.  There may be some
> issues with the inferior code (like the ptrace_ops_hack), but this is
> a fundamental problem with the Linux threads debugging interface.
> Perhaps there simply shouldn't be a LinuxInferior:
>
> i386LinuxInferior IS-A PtraceInferior
>
> where we'de have some Linux-specific helper functions that can be used
> to implement i386LinuxInferior.