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

Mark Kettenis
2004-12-06T14:11:56Z

Date: Sun, 5 Dec 2004 13:45:50 -0500
From: Daniel Jacobowitz <drow@false.org>

This patch converts all GNU/Linux targets to inf-ptrace.c and target vector
inheritance. I was going to do them one at a time, but because the common
native-specific code is so large for GNU/Linux, it was too awkward.

Daniel, thanks for attacking this.

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.

One use of deprecated_child_ops was particularly thorny, so I updated the
to_follow_fork method to take a struct target_ops and push the correct
target. I made to_follow_fork a non-inherited method, like to_xfer_partial.

The comment just above target.c:update_current_target() suggests that
this is a step in the right direction.

This patch leaves some completely dead macros in config/nm-linux.h, and some
mostly-but-not-quite dead macros in various other nm-files. I'll be back.
I didn't want to change more than absolutely necessary, once I was committed
to doing all targets. My next step will be merging the two target vectors
in linux-nat.c.

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.

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

Mark