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

[Andrew Cagney <cagney at gnu dot org>]

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