This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfc] Swap out current when creating a new architecture
- To: Andrew Cagney <ac131313 at cygnus dot com>, gdb-patches at sources dot redhat dot com
- Subject: Re: [rfc] Swap out current when creating a new architecture
- From: Kevin Buettner <kevinb at cygnus dot com>
- Date: Wed, 26 Sep 2001 22:55:46 -0700
- References: <3BB16441.30805@cygnus.com>
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