[rfc/wip] More defensive gdbarch initialization

[rfc/wip] More defensive gdbarch initialization

[Andrew Cagney]

Hello,

This is fallout from the sh-tdep.c bug Elena recently fixed.
I got curious as to how many multi-arch targets might unintentionally be 
refering to the old ``current_gdbarch'' instead of the new gdbarch being 
created.

For instance, code like:

   set_gdbarch_double_bit (gdbarch, 8*TARGET_CHAR_BIT);
   set_gdbarch_long_double_bit (gdbarch, 2*TARGET_DOUBLE_BIT);

would be wrong. TARGET_DOUBLE_BIT refers to the old 
``current_gdbarch'''s double-bit and not ``gdbarch''.  Did anyone 
mention ``Macro's are bad, M'kay''?

So anyway, my idea was to, for the duration of the XXX_gdbarch_init() 
call, invalidate ``current_gdbarch''.  That way the target code couldn't 
use it.  The patch below is work-in-progress on that line.

The thing that makes this funny is that the first bug I found wasn't in 
any target code.  Rather it was in gdbarch.* proper.  gdbarch_alloc() 
contains:

   gdbarch->long_long_bit = 2*TARGET_LONG_BIT;
   gdbarch->long_double_bit = 2*TARGET_DOUBLE_BIT;
   gdbarch->ptr_bit = TARGET_INT_BIT;
   gdbarch->bfd_vma_bit = TARGET_ARCHITECTURE->bits_per_address;

Ulgh ...

You can expect some ``obvious fixes'' related to this over the next ew 
days.  I'll delay any decision to commit something like the change below 
until after 5.1 has branched, it is proving a little too effective in 
finding bugs :-)

Oh for the day when current_gdbarch isn't a global.

	Andrew
From eliz@is.elta.co.il Sat Jul 28 00:31:00 2001
From: "Eli Zaretskii" <eliz@is.elta.co.il>
To: ac131313@cygnus.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [rfa] libgdb updates to doco
Date: Sat, 28 Jul 2001 00:31:00 -0000
Message-id: <1438-Sat28Jul2001103025+0300-eliz@is.elta.co.il>
References: <Pine.SUN.3.91.1010726095158.28739G-100000@is> <3B606479.2070205@cygnus.com> <5567-Fri27Jul2001123713+0300-eliz@is.elta.co.il> <3B61D09E.1000902@cygnus.com>
X-SW-Source: 2001-07/msg00685.html
Content-length: 635

> Date: Fri, 27 Jul 2001 16:35:42 -0400
> From: Andrew Cagney <ac131313@cygnus.com>
> > 
> > How about documenting multi-arch so that I could understand how to
> > multi-arch a target without reading the code? ;-)
> 
> Something based on:
> 
> http://sources.redhat.com/gdb/papers/multi-arch/howto.html

That's just a cookbook.  It's important to have that, but it is no
less important to understand how multi-arch works internally, to be
able to do something beyond blindly following the cookbook.

> still for the moment I'm just trying to fix bits of the documentation 
> that are out-of-date or wrong :-)

Good plan, no doubt ;-)

Re: [rfc/wip] More defensive gdbarch initialization

[Andrew Cagney]

> You can expect some ``obvious fixes'' related to this over the next ew days.  I'll delay any decision to commit something like the change below until after 5.1 has branched, it is proving a little too effective in finding bugs [:-)]


Just FYI, I went as far as investigating the fixes required decided to 
drop any idea of committing any changes in time for 5.1.  The code has 
to both work with and without multi-arch and that quickly makes things 
nasty.

With the branch cut I'll see about a proper solution being committed to 
the trunk.


> Oh for the day when current_gdbarch isn't a global.


Doubled.

	Andrew