What is multi-arch?

[Andrew Cagney <ac131313@cygnus.com>]

Hello,

In the below I'll try to describe, in broad terms, the concept of a
multi-arch debugger and then outline the approach that GDB is taking in
achieving that goal.


What is an architecture?

For GDB, an architecture is a very loose concept.  It can be thought of
as any property of the target that isn't directly dependent on the
current instance of the program being debugged.  The term ``target
architecture'' is some times used.

The ``architecture'' would include:

	o	The ISA (Instruction Set Architecture)
		A specific combination of registers/instructions

	o	Application Binary Interface
		The use of the ISA to provide a specific binary
		interface (stack frame format + register allocation)

while preclude the actual value of a given register.


What is multi-arch?

Such a phrase is fairly loose in its definition so I'll provide you
with a spectrum of definitions:


	o	single architecture debugger:

		For the most part this is what GDB is today.
		If you want to debug a MIPS/32 (O32 ABI) binary
		you build GDB for the MIPS/32.  If you want
		to to instead debug a SPARC (or even a MIPS/64 -
		N64 ABI) then you need to build a second
		(and third) debugger.


	o	multiple architecture debugger:

		The limitation of a single GDB being restricted to
		a single architecture is removed.  A single GDB
		binary being able to debug any of a number of
		architectures for which GDB was built.

		You might build GDB with support for both MIPS and
		SPARC targets.  More typically, however, you will
		be building a GDB with support for a plithera of
		ISA variants (as with the MIPS case).  A very simple
		example is support for both big and little
		byte ordered variants.

		It should be noted that GDB, as it currently stands,
		does support ISA/ABI variants (to a very limited
		degree).  I'm sure that anyone that has hacked on
		that code will agree that, at present, it isn't
		pretty ...

		Of the possibilities, this has the greatest benefit


	o	simultaneous multi-architecture debugger:

		This would have to be the holy grail of debugger
		technology :-)

		(As Stan once mentioned)  Increasingly, in the
		embedded space, people are developing systems that
		are built from several different architectures.
		(To pluck an example out of a hat - the next
		generation PlayStation has been described as
		having a 128-bit main processor as well as a
		number of co-processors).
		http://www.cygnus.com/news/sony1.html

		On the UNIX side, this is still a very applicable
		idea - instead of multiple processors, multiple
		processes, each running a different ABI variant.


GDB?

The objective, at this stage, is to modify GDB so that it can be built
`multi-arch'.

In simple terms, the change required is for all those macro's in
gdb/config/*/tm-*.h to be replaced with corresponding functions.  Those
functions combined into a table (very large architecture object -
gdbarch) - one object per architecture variant.   When establishing a
debugging session, gdb would select/create/install the architecture
variant that best matched what was being debugged.

Of course, it isn't that simple.  Much of GDB's internal code needs to
be tweaked so that it makes run-time rather than compile time
architecture dependent decisions.



In succeeding e-mails I'll be expanding on this,

	enjoy,
		Andrew
From shebs@cygnus.com Mon Apr 19 13:30:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: brendan@dgs.monash.edu.au
Cc: gdb@cygnus.com
Subject: Re: GDB in CVS!
Date: Mon, 19 Apr 1999 13:30:00 -0000
Message-id: <199904191922.MAA18728@andros.cygnus.com>
References: <3716B5A1.404A28C8@dgs.monash.edu.au>
X-SW-Source: 1999-04/msg00049.html
Content-length: 372

   Date: Fri, 16 Apr 1999 03:59:30 +0000
   From: Brendan Simon <brendan@dgs.monash.edu.au>

   I assume these instructions will be on a GDB web page somewhere (just incase
   I can't find this message, my machine dies, etc).

Yes indeed, they'll go into the GDB pages on sourceware (in fact these
instructions were lifted from the autoconf pages there...).

								Stan
From shebs@cygnus.com Mon Apr 19 13:32:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: jauming@yahoo.com
Cc: gdb@cygnus.com
Subject: Re: newbie question
Date: Mon, 19 Apr 1999 13:32:00 -0000
Message-id: <199904191956.MAA18773@andros.cygnus.com>
References: <19990419081407.2019.rocketmail@send102.yahoomail.com>
X-SW-Source: 1999-04/msg00050.html
Content-length: 655

   Date: Mon, 19 Apr 1999 01:14:07 -0700 (PDT)
   From: JauMing Tseng <jauming@yahoo.com>

   1)is [gdb stub] needed by [pmon of mips]?

No.

   2)which protocol is better?
     a)pmon mips remote debugging protocol
     b)native gdb remote debugging protocol

GDB's native protocol, of course. :-) But seriously, the mips protocol
is less efficient, requiring more line traffic, and it's binary, which
makes debugging harder.  It's also a little more complicated, which
likely means more target-side code to write.

All in all, I would recommend the use of GDB's own protocol, unless
you have some other reason to use PMON in your target.

								Stan