Re: [RFC/RFA] Target vectors for native Linux targets

[Daniel Jacobowitz <drow at false dot org>]

Comments on the actual patch to follow, separately.

On Sun, Aug 21, 2005 at 05:20:59PM +0200, Mark Kettenis wrote:
> > From: Ulrich Weigand <uweigand@de.ibm.com>
> > Date: Sun, 21 Aug 2005 15:28:31 +0200 (CEST)
> > 
> > Mark Kettenis wrote:
> > 
> > > Hmm, it would be preferable to have it the other way around, since
> > > that would make eliminating the nm-linux.h files, but I can see why
> > > you did it this way.  In the end we might just define USE_LINUX_TARGET
> > > if GDB_NM_FILE isn't defined.  So it's not really important.  I've
> > > added some more comments on the patch inline.
> > 
> > I guess we could make a config/nm-new-linux.h or something -- that
> > would be a (temporary) new nm file, but would allow to remove the
> > per-platform Linux nm files as platforms are converted over ...
> 
> Don't bother.  All the cruft in there has to go away eventually.
> Making it more cruftier in the meantime isn't a problem.

Half of Mark's followup comments were about the mechanism to do this a
target at a time.  Let's not.  My original patch covered every single
GNU/Linux target and I tested more than half of them.  I don't know if
I'll redo the mammoth testing sequence this time, but only a handful
(i386, ia64, s390, maybe sparc? don't recall) were particularly unique.
I have access to the great majority of GNU/Linux targets supported by
GDB for testing.

> > > Daniels earlier attempt had linux_target accept a `struct target_ops
> > > *' as an argument to serve as an alternative for a plain
> > > inf_ptrace_target().  I thought that was necessary for i386 and sparc
> > > Linux targets, but I think I've convinced myself that it isn't.

My goal was not just to start using inf_ptrace_target, but to unify the
single-threaded and multi-threaded target vectors.  The multi-threaded
target provides its own to_resume which calls child_resume. 
i386-linux-nat.c provides its own child_resume which works around an
old Linux kernel bug.

In Ulrich's patch, the target could modify linux_ops, which is exposed
to it by the return value of linux_target ().  This would cease to work
when linux_target started to return a multithreaded target.

But the way I did it was pretty ugly and Andrew's suggestion in the
followup discussion was much nicer (barring naming); just provide a
hook in linux-nat.h to implement the same functionality differently.
And I've got some other ideas on how to neaten it up, though they may
not turn out to be useful.

I've learned some interesting things from reading Ulrich's patch.  I'm
going to stitch the two together this afternoon.

> > Since you can always override the target functions afterwards,
> > I'm not sure why this would be necessary ...
> 
> I think Daniels earlier patch did things a little bit differently,
> eliminating the Linux pseudo-LWP layer.  That made overriding things
> afterwards more difficult.  All the more reason to go with your patch
> instead of reviving Daniels old one.

There's a lot of complexity and target-stack-violation caused by the
fact that the GNU/Linux "child" stratum can't handle multithreaded
applications.  It really needs to die.

-- 
Daniel Jacobowitz
CodeSourcery, LLC