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

Andrew Cagney
2004-12-14T02:06:02Z

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