This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc] [17/17] Get rid of current_gdbarch in go32-nat.c
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: drow at false dot org (Daniel Jacobowitz)
- Cc: eliz at gnu dot org (Eli Zaretskii), deuling at de dot ibm dot com (Markus Deuling), gdb-patches at sourceware dot org
- Date: Wed, 24 Oct 2007 15:38:41 +0200 (CEST)
- Subject: Re: [rfc] [17/17] Get rid of current_gdbarch in go32-nat.c
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