This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.

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

Re: breakpoint extension for remote protocol


   From: Jim Blandy <jimb@cygnus.com>
   Date: 16 Feb 1999 13:49:54 -0500

   For the record, Zdenek Radouch pointed out a while back on the
   internal GDB mailing list a distinction that I liked:

   There are actually three "architectures" that we care about:
     - the architecture of the processor itself
     - the ABI and calling conventions (controlled by the compiler/linker
       environment)
     - the target board architecture (excluding the CPU)

Yes, this is a good mental model.

   At present, we kind of smoosh them all together, which causes
   confusion when someone else needs to wade into our code and
   disentangle our assumptions.  We support multiple ABI's for the MIPS
   and PPC (at least), and (I think???) you have to select the one you
   want at configuration time (--target=powerpc-eabi, for example).  So
   we are already drifting away from "generic" embedded toolchains, which
   I agree is bad.

This is a leftover from native debugging, where the configure-time
choice of host OS determines architecture and ABI.  In fact, even
CPU variants are often reduced down to a single "programmer's model"
that restricts access to some of a chip's features (like supervisor
mode :-) ).

   When we estimate new GDB ports, we should include time to actually
   segregate those three things nicely, so that GDB could have a "set
   abi" and "set board" command.  Otherwise, if GDB is really to know all
   that stuff (as Stan has said it should), it's going to be a total mess.

In general, GDB should not have to know much about specific boards;
things are simplified overall if the board support package takes care
of board idiosyncrasies, so for instance GDB can say "write memory"
and the board does one thing for flash, and something else for RAM.

ABI is clearly a weak point, and in the mercifully few cases of chips
with multiple ABIs, we do need to make the choice dynamically rather
than statically, preferably automatically by studying the code, but
with a manual "set abi" command to handle failures of automation.

Unlike with GCC, there is little or no advantage to compiling GDB's
target knowledge in at build time.  So we should be moving towards
making it more dynamic overall.

							Stan