Re: [rfc] Swap out current when creating a new architecture

[Andrew Cagney <ac131313 at cygnus dot com>]

> Just a quick recap: what the old code was doing by referring to
> current_gdbarch was to avoid changing the ABI (which I infer from the
> bfd) if one of the other target specific commands were being used.  The
> patch below sets the abfd field in the info struct to exec_bfd before
> calling gdbarch_update_p, so that information on the current bfd is
> passed along, just as it is when gdbarch_update_p is called from
> set_gdbarch_from_file.
> 
> Is this an acceptable way of doing it?  I know I'm in the risky business
> of dealing with global pointers.  (I'm assuming a commit could go on
> both trunk and branch.)
> 
> Nice bug! I need to think about this some more though.

Really nice bug!

The proposed change unfortunatly isn't right for reasons similar to the 
original current_gdbarch problem.  The exec file might belong to a 
completely different architecture.  Consider a sequence like:

	(gdb) file hello.d10v
	(gdb) info architecture
	The current architecture is d10v
	(gdb) set cris-mode CRIS_MODE_USER

For MIPS, the problem has so far been avoided by coding functions as:

	if (set by user)
	  return user value;
	else
	  return value from architecture;

I should note though, that even this will eventually have problems - it 
affects all MIPS architectures - but at least it gets over the immediate 
hurdle.

enjoy,
Andrew