tom@ssd.csd.harris.com (Tom Horsley) (10/25/90)
If anyone knows of any debuggers out there with features that might be
considered "realtime", please let me know. I am interested in both research
and commercial products.
The sort of things I am looking for:
o Multi-language capability (Ada, C, Fortran, C++, etc).
o Low overhead (possibly runs most of the debugger on a separate machine
to avoid impact on the realtime system being debugged).
o The ability to debug multiple processes (or Ada tasks, or both) from
the same debug session and examine interactions between the tasks.
o Nice user interface - possibly X based.
I am not sure if any such beast exists, but it doesn't cost much to post a
note and ask. If I get any useful information, I will summarize and post.
Thanks in advance for any information you can provide.
--
======================================================================
domain: tahorsley@csd.harris.com USMail: Tom Horsley
uucp: ...!uunet!hcx1!tahorsley 511 Kingbird Circle
Delray Beach, FL 33444
+==== Censorship is the only form of Obscenity ======================+
| (Wait, I forgot government tobacco subsidies...) |
+====================================================================+fisher@edwards-vax.af.mil (10/25/90)
In article <TOM.90Oct24161602@hcx2.ssd.csd.harris.com>, tom@ssd.csd.harris.com (Tom Horsley) writes: > If anyone knows of any debuggers out there with features that might be > considered "realtime", please let me know. I am interested in both research > and commercial products. > > The sort of things I am looking for: > > o Multi-language capability (Ada, C, Fortran, C++, etc). > > o Low overhead (possibly runs most of the debugger on a separate machine > to avoid impact on the realtime system being debugged). > > o The ability to debug multiple processes (or Ada tasks, or both) from > the same debug session and examine interactions between the tasks. > > o Nice user interface - possibly X based. The debugging capabilities found in DIGITAL'S VAXELN realtime executive have most of the things you are requesting (I don't know about Ada tasking or the X interface for certain).
dwells@fits.cx.nrao.edu (Don Wells) (10/26/90)
In article <TOM.90Oct24161602@hcx2.ssd.csd.harris.com> tom@ssd.csd.harris.com (Tom Horsley) writes: From: tom@ssd.csd.harris.com (Tom Horsley) Newsgroups: comp.realtime Date: 24 Oct 90 20:16:02 GMT Organization: Harris Computer Systems Division If anyone knows of any debuggers out there with features that might be considered "realtime", please let me know. I am interested in both research and commercial products. Take a look at vxWorks from Wind River Systems. Their "first generation" technology for fancy source-level debugging is based on Sun's "dbxtool". In fact, in order to have remote source-level debugging, you purchase a special version of dbxtool called "dbxWorks" from Sun Consulting. It is dbxtool plus capability to talk to a remote debug server. The sort of things I am looking for: o Multi-language capability (Ada, C, Fortran, C++, etc). Yes, dbxWorks from Sun for vxWorks does this, because dbxtool (in fact, dbx itself) does it. In my RT project we use both C and Fortran. I can't speak for Ada or C++ or Pascal or ...; check out the specs for dbxtool language support. o Low overhead (possibly runs most of the debugger on a separate machine to avoid impact on the realtime system being debugged). I don't think that this is a relevant consideration. o The ability to debug multiple processes (or Ada tasks, or both) from the same debug session and examine interactions between the tasks. dbxtool (dbx) does not deal with multiple processes from a single instance of dbx on the Sun, and so it doesn't deal with that case on vxWorks either. HOWEVER! It is perfectly feasible to open two separate windows on the Sun with separate copies of dbxWorks and have them talk to the same vxWorks RT host debug server and use them to step through (and display source for) two different RT processes. This is *wonderful* when you are trying to debug a hand-shaking protocol between the processes: you can step up to the rondevous (I mean this in the generic sense, not in the sense of Ada rondevous semantics) in one process and watch it pend on the signal (whatever it is) that has not yet arrived from the other process, and then -- in the other window -- you step the other process up to the critical region of the protocol and step into sending the signal (whatever it is). In the other window you see the signal arrive, and the execution steps to the next statement! (Or then, maybe, it *doesn't* arrive, and you have found your bug.) You can easily print out local variables and examine data structures in both processes at each step of your protocol. o Nice user interface - possibly X based. Sunview is not going to be the ultimate windowing standard, but it still qualifies for adjective "nice". Sun will have, and probably already have, versions of dbxtool/dbxWorks for OpenView/OpenLook under X. I don't know, because my project is still Sunview-based. =-=-= Second Generation? =-=-= Wind River Systems has decided to change debugger technology: they will switch from Sun's dbxtool/dbxWorks to FSF's "gdb" GNU debugger. The capability will be similar, but the style of interface will be different. More important, gdb is computer-vendor-independent and portable to many architectures. Because of the nature of the GNU copy-left license it *may* be that the development work to add remote RT host interfacing to gdb will enter the public domain, and therefore it *may* turn out that this will become a de facto standard RT source debugger interface; we shall see... The FSF GNU products will be (and in many cases, already are) X-based. -- Donald C. Wells, Assoc. Scientist | dwells@nrao.edu Nat. Radio Astronomy Observatory | 6654::DWELLS Edgemont Road | +1-804-296-0277 38:02.2N Charlottesville, VA 22903-2475 USA | +1-804-296-0278(Fax) 78:31.1W