[RFC 00/32] clean up target delegation

[Tom Tromey <tromey at redhat dot com>]

This patch series cleans up most of the target API.

It changes nearly every target method to take a "self" argument.  This
was done in a mostly automated way.  This is PR 8626.

It introduces a new script, and some new annotation-like macros in
target.h, to change how delegation, and the base case, are handled for
nearly every method in target_ops.  This seems like it resolves PR
7701, at least from my point of view.

The justification for the "self" arguments comes primarily from
multi-target: eventually each layer of the target stack may be its own
object with its own state.  Adding the self arguments guarantees a
simple way for a given layer to access the relevant state; and a
simple way to handle delegation, should it be needed.

Regularizing the delegation is part of this series because the above
requires care when making a delegating call -- care not always taken,
I think, in the current tree.  In particular, it is important to call
a method in a given stratum's method with that stratum's target_ops
pointer.

I took the approach of using a new script that reads target.h and
extracts the method information.  I chose this approach because it is
quite easy to work with as a developer -- target.h is just plain C
code, generally following rules we already follow.  An alternate
approach might be something like gdbarch.sh, but I've long considered
that unreadable.

The original patch series consists of 231 patches -- I did each method
conversion as a separate patch, to make it simpler to fix problems
during development.  To make it less awful on the list, I've combined
groups of ~10 patches in each of the blocks of rote patches.  I merged
them in a completely automated way; so the log messages are a bit
"weird" -- just the concatenation of each patch's log.

If you want to see the atomized series in its full glory, it is all on
the "target-cleanup" branch in my gitorious repository.  If you think
it would be better if I sent the atomized patch series to the list,
I'm happy to do that as well.

Because this touches every target, I built this on many platforms.  I
mostly did build tests because most of the patches are obviously
semantically neutral.

   x86-64 Fedora 18 (native).  I built every revision (cumulatively of
   course).  Regression tested native and with the native-gdbserver
   target board.
   x86-64 Fedora 18, cross build with Mingw tools.  I cross built each
   revision.
   PPC64 Linux (gcc110 in the compile farm).  Built each revision both
   normally and with the SPU target enabled.
   AIX (gcc111 in the compile farm).
   NetBSD 5.1 (gcc70 in the compile farm).

Of course, this probably still introduces bugs.  On the plus side, any
compile time bug will be trivial to fix.


After this patch, nearly every remaining INHERIT is for a scalar
field.  I think it would be worth eliminating these as well; the
simplest would seem to be to convert each to a new target method.  I'm
happy to do this if others agree.

The remaining method using INHERIT is deprecated_xfer_memory.  This is
also a method not using delegation or getting the "target_ops"
treatment.  I didn't bother with this one because my understanding is
that Pedro is working on eliminating this method entirely.

There are also three remaining uses of de_fault: to_open, to_close,
and deprecated_xfer_memory.  to_open and to_close are just special.
They may need some work for the multi-target feature, but I didn't
want to attempt it now.  deprecated_xfer_memory, again, is hopefully
just going away.


There are also still a few methods not using the new delegation
scheme: 

    to_has_all_memory to_has_memory to_has_stack to_has_registers
    to_has_execution to_supports_non_stop to_get_thread_local_address
    to_thread_address_space to_fileio_* to_info_proc

I'll fix to_fileio_* soon.

In each of the other cases, the method in question is used in a way
that isn't readily convertible to the current delegation scheme.  I
left converting these for the future.


Please read through this as much as you are able.  I myself plan to
leave it for a little while, then come back and re-read each patch
(ugh) for sanity; then rebase (ugh).  Naturally I will fix up any
review requests.  When pushing I think I will push the atomized
series, not the one that is bundled for review.

Tom