From mboxrd@z Thu Jan  1 00:00:00 1970
From: Kevin Buettner <kevinb@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: [rfc] Swap out current when creating a new architecture
Date: Wed, 26 Sep 2001 22:56:00 -0000
Message-id: <1010927055546.ZM3074@ocotillo.lan>
References: <3BB16441.30805@cygnus.com> <ac131313@cygnus.com>
X-SW-Source: 2001-09/msg00384.html

On Sep 26,  1:14am, Andrew Cagney wrote:

> The attached changes the run-time environment within which a new 
> architectures are created.  Briefly the simplified sequence:
> 
> - call XXX_gdbarch_init()
> - swap out old architecture
> - install new architecture
> 
> is changed to:
> 
> - swap out old architecture
> - call XX_gdbarch_init()
> - install new architecture
> 
> This has the effect of making current_gdbarch invalid for the lifetime 
> of the XXX_gdbarch_init() call.
> 
> The motivation behind this change is to stop XXXX_gdbarch_init() 
> functions refering (unintentionally I suspect) to the previous 
> architecture.  I think it is proving effective since it has so far 
> flushed out two bugs.
> 
> I can think of one additional tweek: add a ``gdb_assert (gdbarch != 
> NULL)'' to each architecture method.  Without it a XXX_gdbarch_init() 
> function that tries to use current_gdbarch will dump core :-/
> 
> thoughts?

I've read your patch and it looks okay to me.

I'm wondering though if it might be possible to set current_gdbarch
to the architecture currently getting defined.  This way, it would
be possible to do things like:

    gdbarch->target_long_bit = 8;
    gdbarch->target_long_long_bit = 2*TARGET_LONG_BIT;

It seems to me that the trick is to figure out a clean way to
set it.  It occurred to me that it could be set in gdbarch_alloc(),
but that doesn't really seem too clean... The only other thing I
can think of is to have (the various) <arch>_gdbarch_init() make
an explicit call which'd cause current_gdbarch to be set.  After
that, the <arch>_gdbarch_init() could refer to TARGET_LONG_BIT, etc.
if they wanted to.  Such a call would be optional; if this call
isn't made, then it's not permissible to refer to the macros...

My other thought on this matter is that all of what I just said
is complete nonsense and that we're better off with current_gdbarch
being NULL to avoid referring to a partially defined architecture...
if that's the case, then adding a NULL check to each architecture
method would indeed be a good thing.

Kevin