Re: [00/19] Eliminate some more current_gdbarch uses

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

> this series of patches makes some more progress towards the goal of
> eliminating the current_gdbarch global.  This series tackles remaining
> instances that are relatively simple to eliminate using existing
> mechanism and relatively "local" changes.
> 
> While some patches in the series do change existing interfaces to
> allow passing architecture information to some lower level, these
> are typically less-frequently used ones that require only limited
> changes to the rest of GDB.
> 
> After this patch series, the remaining instances of current_gdbarch
> are difficult to eliminate, typically within frequently-called
> central infrastructure routines.  A follow-on patch series will
> address those remaining occurrences.
> 
> This patch 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!  I plan on committing the series within a week
> or two (after I'm back from the GCC Summit).

I've now checked this series in, with the exception of:

[03/19] set_longjmp_breakpoint
(I'm still rewriting this as discussed.)

and

[16/19] address class support
(We're still discussing whether a type should always be associated
with an architecture; if so, this patch is no longer needed.)

Bye,
Ulrich

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