This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] Use target vector inheritance for GNU/Linux
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