From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cagney <ac131313@cygnus.com>
To: Orjan Friberg <orjan.friberg@axis.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [rfc] Swap out current when creating a new architecture
Date: Mon, 15 Oct 2001 18:41:00 -0000
Message-id: <3BCB902A.8090003@cygnus.com>
References: <3BB16441.30805@cygnus.com> <3BB771A1.4070201@cygnus.com> <3BB854B3.208DC17A@axis.com> <3BCA28A3.6010607@cygnus.com>
X-SW-Source: 2001-10/msg00227.html

> 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