Re: breakpoint extension for remote protocol

Stan Shebs
1999-04-01T00:00:00Z

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