Re: [rfc] [17/17] Get rid of current_gdbarch in go32-nat.c

["Ulrich Weigand" <uweigand@de.ibm.com>]

Daniel Jacobowitz wrote:
> On Tue, Oct 23, 2007 at 10:53:03PM +0200, Eli Zaretskii wrote:
> > I can understand why this is a Good Thing for ports that can actually
> > support multiple architectures.  But why is this a good idea for
> > single-architecture ports?  You are replacing a variable reference
> > with a function call, which is a slowdown.  That's the downside;
> > what's the upside, please?
> 
> Even a single-architecture port may have more than one
> current_gdbarch.  A gdbarch is fine-grained and e.g. different
> executables can lead to different gdbarches.  So a GDB for DJGPP which
> supported debugging two programs at once might need more than one
> "current" gdbarch.
> 
> Also, getting rid of current_gdbarch is hard.  If we leave it
> in some targets then we have to continue making it work; it'll
> creep back in to ports that were trying to get rid of it.  I
> think having more than one way to do this is not worthwhile.

Yes, that's my main concern as well.

However, getting back to the specific case of the go32-nat.c changes:

-  if (regno < gdbarch_fp0_regnum (current_gdbarch))
+  if (regno < gdbarch_fp0_regnum (get_regcache_arch (regcache)))

I actually agree with Eli that this is probably not the right way;
instead the "gdbarch_fp0_regnum (current_gdbarch)" should be replaced
by simply I386_ST0_REGNUM -- this is the only value gdbarch_fp0_regnum
can ever have on i386 targets.  (Of course, this will also get rid
of this particular use of current_gdbarch, which is my main concern.)

> > Good God! you don't really mean that, do you?  What kind of bloated
> > GDB executable will we have when this happens?
> 
> FYI, I'd love to ship a single GDB binary that supported multiple
> targets.  That's practical for our case.  I don't know if we would
> turn on all targets or just a set list.

Actually, I'm just preparing to send out a patch set to do just that :-)

The only remaining prerequisites are that the solib patches are applies,
and the final remaining TM file tm-frv.h is removed.

The patches will provide the --enable-targets= configure option, which
will work just the same as this option today works with binutils: you
will always get the "main" target (--target ...), and in addition
support for all targets listed with --enable-targets= is compiled in.
A special case is --enable-targets=all, which will support all targets
GDB has.  Those extra targets can be remote targets only; only the
main target can be the native target (when appropriate).

Bye,
Ulrich

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