From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: gdb@cygnus.com Subject: What is multi-arch? Date: Mon, 19 Apr 1999 09:56:00 -0000 Message-ID: <371B4A91.7A2FDB82@cygnus.com> X-SW-Source: 1999-04/msg00048.html Message-ID: <19990419095600.jyfSvmdbwxblLMbcRzE4QeglsfBDQ_1kEzVE7GtXpSk@z> 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 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 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 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 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