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

[Daniel Jacobowitz <drow@false.org>]

On Mon, Dec 06, 2004 at 03:10:42PM +0100, Mark Kettenis wrote:
>    A new function, linux_target, is added to linux-nat.c.  Then any GNU/Linux
>    target can call it, and pass the result to add_target - after specializing
>    whatever methods it needs to.  Sometimes it's necessary to specialize a
>    method between inf_ptrace_target and linux_target, so it accepts an optional
>    argument.
> 
> Yes, indeed, in particual the way the various Linux ports deal with
> reading and writing registers is really different.
> 
>    This wouldn't be necessary if all target methods took a
>    target_ops parameter, so they could call the overridden method.
> 
> I don't think so.  The target_ops parameter is intended to provide a
> way for strata to "inherit" stuff from other strata (i.e. the
> core_stratum inheriting the to_xfer_partial method from the
> file_stratum).  Here we're talking about inheriting stuff from a
> prototype vector within a single stratum.

Right now the only thing I need this for is to find a method in this
target and stratum.  i386-linux-nat.c provides to_resume, and
linux-nat.c used to call child_resume directly (because it can't use
target_resume, which would go through thread-db and back to linux-nat
again).  So I have to somehow pass the pointer to the i386 resume to
linux-nat.c, and this seemed like the right way.

So from a short-term, literal perspective, what I wrote is correct: the
only reason that there is a target_ops argument to linux_target would
be unnecessary if there were more target methods that took their own
target_ops argument.

Long-term, with the target_ops arguments added, I'm really not sure. 
The only difference would be whether the i386-linux version calls or is
called by the generic GNU/Linux version; and for all the examples I've
looked at, it doesn't matter.

>    I've tested this patch with the full testsuite on x86_64-linux and
>    i386-linux, partial testsuite on ia64-linux [it gets hung up in an
>    infinite loop in sigaltstack.exp with or without the patch], and smoke
>    testing on s390x [the machine I was using didn't have expect].
> 
> I'll try to test & cleanup sparc and possibly sparc64.

Thank you very much!  Randolph has also tested hppa-linux for me.

>    Comments?  Proofreading?  I'm going to let this sit for a couple of days,
>    because (while mechanical) it's very large - I think I got everything, but
>    since I don't have the resources to test on every single GNU/Linux native
>    target, I can't be sure.
> 
> I'm just wondering whether the saved_xxx variables should be called
> linux_saved_xxx instead.  Probably not...

Possibly, by analogy to the methods using them.  I can rename if you'd
prefer.

-- 
Daniel Jacobowitz