[RFC] Use target vector inheritance for GNU/Linux

Andrew Cagney cagney@gnu.org
Tue Dec 14 15:41:00 GMT 2004


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



More information about the Gdb-patches mailing list