Re: breakpoint extension for remote protocol

[jtc@redbacknetworks.com (J.T. Conklin)]

>>>>> "shebs" == Stan Shebs <shebs@cygnus.com> writes:
jimb>  There are actually three "architectures" that we care about:
jimb>		- the architecture of the processor itself 
jimb>		- the ABI and calling conventions (controlled by the
jimb>		  compiler/linker environment)
jimb>		- the target board architecture (excluding the CPU)

I think the second point could be further subdivided.  For the most
part, GDB only cares about the calling conventions.  But in some
cases, for example with setjmp()/longjmp(), it wants to know the
internals of the implementation.  There is no guarentee that my
setjmp()/longjmp() implementation is going to store registers in
the same order as anyone elses.

I'm not quite sure what is meant by target board architecture,
hopefully whatever back end GDB uses (the remote protocol, a ROM
monitor, etc) abstracts and isolates it from the target board.

shebs> Yes, this is a good mental model.

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

I think it's not so much drifting away from "generic" toolchains.  The
infrastructure for generic toolchains wasn't/isn't in place, and it is
a lot of work to retrofit.  

It used to be much worse.  When I joined Cygnus, I believe there were
several m68k toolchains --- as GDB backend and newlib target support
for the various eval boards were separate configs.

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

And MMU and other system registers, etc.

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

And also so you have a complete product in the end.  For example,
there've been many new GDB ports done, but there haven't been many new
stubs.

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

Agreed, write protected RAM, EEPROM, flash, banked memory, etc. should
all be handled by the code in the stub that handles the 'write memory'
command.  Using a vendor-supplied ROM monitor might require additional
knowlege by GDB about the target and "helper" routines in the
application.  Bleh.  That's too ugly to think about.

	--jtc

-- 
J.T. Conklin
RedBack Networks