This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Re Multi Arch Architecture


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]