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

[Daniel Jacobowitz <drow@false.org>]

On Tue, Oct 23, 2007 at 10:53:03PM +0200, Eli Zaretskii wrote:
> Well, that just says its purpose is to get rid of current_gdbarch, but
> there's no serious discussion of the issue.  So I'm still wondering:
> was this discussed, and if so, where can I read it?

I believe it was Andrew's goal as long ago as when he started adding
"gdbarch" arguments to methods.  I can't think of any specific
discussion, but I've been aware of this trend as long as I can
remember working on GDB.

> 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.

> 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.

> > This is a cool feature ;-) Whereas I cannot imagine a scenario
> > where GDB debugs for example an x86 binary and a PowerPC binary in one session.
> 
> If we cannot imagine such a scenario, why are we trying to support it?

I can imagine it; people build such systems today, and some of
CodeSourcery's customers are interested in debugging them.  Of course,
that's not a terribly frequent example, but there's all sorts of
weird hybrids out there.  An ARM and a signal processor or a PowerPC
and eight SPUs are both real cases I'm familiar with.

-- 
Daniel Jacobowitz
CodeSourcery