This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Re Multi Arch Architecture
- To: DJBARROW at de dot ibm dot com
- Subject: Re: Re Multi Arch Architecture
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Fri, 20 Oct 2000 20:10:14 +1100
- Cc: Michael Snyder <msnyder at redhat dot com>,gdb-patches at sourceware dot cygnus dot com
- References: <C125697C.005DECA4.00@d12mta09.de.ibm.com>
DJBARROW@de.ibm.com wrote:
>
> Hi,
> Nobody attempted to answer any of my questions I posted to you last week,
>
> I'm most of the way through adding the multi arch definitions & am
> absolutely convinced that
> the 64 bit s390 port is less work. Who is responsible for implementing this
> & worse still letting
> it into the CVS repository & gdb-5.0, it appears to be only half thought
> out.
>
> 1) For instance on linux/sparc & our up & coming 64 bit port we will be
> able to run
> 32 bit applications & 64 bit applications on the 64 bit machine.
> However the definitions of LONGEST & CORE_ADDR are still hard types in gdb
> & so
> you cannot switch between 32 bit applications & 64 bit applications with
> this one copy of gdb
> ( which is the only use I can see for a multi arch gdb I can think of
> unless you were working on some kind of
> perverted machine with different types of processors ), this proble clearly
> hasn't been sorted
> out yet possibly 1000 man hours has been spent moving all the stuff to this
> apparently broken code.
FYI, LONGEST is defined to be the largest integer supported by the HOST
system. The configury stuff should be setting it a ``long long'' (i.e.
64 bit value) on all modern systems.
CORE_ADDR is defined to be a host integer type that is large enough to
store a cannonical target address. The relationsip:
TARGET_PTR_BIT <= sizeof(CORE_ADDR)*8
holds. It is important to note that the relationship:
TARGET_PTR_BIT == sizeof(CORE_ADDR)*8
is *NOT* true.
In the case of targets that want to support both 32 and 64 bit ISAs (or
ABIs) you simply need to ensure that CORE_ADDR is large enough to store
a 64 bit value. The MIPS and SPARC targets demonstrate this working.
If somone tries to implement something like a target with a 128 bit
address on a host with only a 64 bit LONGEST then there will be a
problem. Changing CORE_ADDR to an object is somewhere on the long list
of proposed changes to GDB. Fortunatly we've so far managed to avoid
that change :-)
> 2) Everything done in the current GDB_MULTI_ARCH stuff could be done in a
> similar automatically generated
> way like ./configure does with autoconf m4 & other stuff using the original
> gdb definitions in /config/arch/ by someone
> with half a brain & willing to spend the 100+ man hours required to
> implement it properly.
Unfortunatly experience has taught me that it will take a little bit
more than the ~100 hours you suggest.
Firstly of the changes are not mechanical (updating the struct
frame_info stuff for instance) and secondly in converting a target the
developer can't simply rely on some mechanical process. Instead they
must demonstrate that their change has not broken the target in qustion.
> 3) I have to pull a lot of definitions out of header files which I could
> have used elsewhere.
If you need to share something between the gdb/s390-nat.c and
gdb/s390-tdep.c files then I'd suggest putting it in:
gdb/s390-tdep.h
and including it in both.
> 4) Is it difficult to gdb bfd to work multi arch ???
>
> In short I think the code was a lot better the way it was.
I agree the initial speed bump is a definite pain. However, once you're
into the build test cycle you'll see immediate benefits. The cycle:
o compile s390-tdep.c
link
run
is a lot faster than
re-compile everything
.
.
.
.
link
run
enjoy,
Andrew