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

[Mark Kettenis <kettenis@gnu.org>]

   Date: Mon, 13 Dec 2004 21:03:34 -0500
   From: Andrew Cagney <cagney@gnu.org>

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

Yup.

   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.

I'm all for removing that hack when it's no longer necessary.
However, before we decide that it isn't, we should make sure that we
won't hurt existing users by doing so.  IIRC you fixed this a couple
of months ago.  So there are probably still many people using kernels
that aren't fixed.  Was your bugfix backported and accepted in the
Linux 2.4 kernel?  Anyway, We once claimed that we support Linux 2.0
and up.  This probably doesn't make sense anymore, but there are
probably still many Linux 2.2 systems out there that people would like
to use the latest GDB on.  So I suspect it is still too early to
remove this code.

Meanwhile, it'd be great if you could add something to the comment
that states the problem has been fixed.  Please add the version(s) of
the official Linux kernel where this was fixed, and when they were
released.  That will make it easier for us to decide when to remove
this code.

But even then, this is just one case of where platform-dependent
"fixes" for the generic ptrace code are necessary.  I think GDB should
still allow for such bits of code in the future.

Thanks,

Mark