[00/15] Completely eliminate current_gdbarch

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Hello,

this set of patches, on top of the series I posted previously,
completes removal of the current_gdbarch global.

This requires adding gdbarch pointers to a number of data structures
to make them gdbarch aware:
 - threads & frames
 - breakpoints
 - values

When looking into this last year when eliminating use of builtin_type
macros, I tried to avoid making values and types per-architecture:
http://sourceware.org/ml/gdb-patches/2008-09/msg00033.html

However, for the case of values, it seems this was not the right
decision: the contents stored in a value object fundamentally
depend on the architecture, starting from the byte order, and
including questions like floating-point format and pointer to
address conversion conventions.

So in this patch set I've reversed that decision and made value objects
explicitly per-architecture; this requires every place that creates a
value object to explicitly specify an architecture.

Note that type objects are still platform-neutral, because they are
typically created just from the symbol file data, and because we
explicitly want to preserve the capability to define global types
like builtin_type_void or builtin_type_int32.

Making values per-architecture actually allowed me to revert two of
the most un-obvious constructs I had to use in the builtin_type
patches: using the objfile architecture in find_function_in_inferior
and in the C++ ABI logic ...


Apart from making those data structures per-architecture, I'm adding
a new function get_current_arch () that is intended to be used by
top-level UI command implementations; it gets at a "current architecture"
to be implicitly used for executing a command.  This is generally the
architecture of the selected frame.

The rest of the patch set is bascially straightforward, if somewhat
tedious;  several very frequently used routines that use current_gdbarch
implicitly needed to be modified to have an architecture (or whatever
defining feature that particular call requires) passed in from the
caller.  The bulk of the patch set is then simply updating all affected
call sites.

There's one case that required special hacks: eliminating use of
current_gdbarch from callback routines called from the Python
interpreter.  See the comments on that patch for more details ...


This patch series (on top of the previous series) was tested with
no regressions on amd64-linux, powerpc64-linux, spu-elf, s390-ibm-linux,
and s390x-ibm-linux.  Also, I made sure an --enable-targets=all build
still succeeds.

Comments welcome!  If there are no objections, I'd like to
commit this a week or two after committing the previous series ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com