This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Debugging from ROM


Hi all,
I'm not sure if debugging from ROM is something that has been done very
often with eCos and gdb -- perhaps targets/processors with hardware
breakpoints allow this.

But it seems that eCos is geared (at least somewhat) for debugging out of
RAM with the help of a ROM monitor.  Here, a debugging scenario entails
linking your client code with a RAM-enabled eCos library and loading it into
RAM through the gdb stub.  In general this is a very nice debugging
facility.  But since your target application will typically be running out
of ROM this poses some limitations, especially if you are RAM-constrained
and your target app won't fit.  And as luck would have it, even if the app
does fit, bugs don't always behave the same when running out of RAM vs ROM.

A more convenient scenario which offers more freedom would be to have the
target running out of ROM.  And when the developer wants to, he/she can
attach a debugging cable and break the program and examine what is going on
through a remote gdb session.  After poking around he/she can resume the
program and unplug the debugging cable to let the system resume doing its
thing.

Debugging out of ROM requires some kind of special mechanism on the platform
for setting breakpoints, but lets assume that we have this.  If we have the
gdb stub compiled into our ROM target we should be able to "wake" the stub
through an interrupt on the communication channel and break the program
execution.  ONe idea to have the diag console outputting raw data until it
gets a gdb character '$' and then it switches to a gdb-mangler data (sorta
like RedBoot does)  We continue in "gdb mode" until we get a $k#6b packet
from gdb quitting and then we resume the program (and the console goes back
into raw mode).   Switching console modes could be done by rearranging the
virtual vectors (say)

Is this reasonable?  It's likely that I've overlooked something or
somethings.  Or maybe this has been done before..  REgardless, any comments
would be greatly appreciated.

Thanks!
Rich LeGrand



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


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