|[4 earlier articles]|
|Re: debuggers - request for information firstname.lastname@example.org (1995-07-18)|
|Re: debuggers - request for information email@example.com (1995-07-18)|
|Re: debuggers - request for information firstname.lastname@example.org (1995-07-19)|
|Re: debuggers - request for information email@example.com (1995-07-20)|
|Re: debuggers - request for information firstname.lastname@example.org (1995-07-20)|
|Re: debuggers - request for information email@example.com (1995-07-20)|
|Re: debuggers - request for information R.Sosic@cit.gu.edu.au (1995-07-21)|
|Re: debuggers - request for information reid@HASKELL.SYSTEMSZ.CS.YALE.EDU (1995-07-22)|
|Re: debuggers - request for information firstname.lastname@example.org (1995-07-25)|
|Re: debuggers - request for information email@example.com (1995-07-26)|
|Re: debuggers - request for information firstname.lastname@example.org (1995-07-27)|
|Re: debuggers - request for information 100341.3447@CompuServe.COM (Clive Harris) (1995-08-01)|
|Re: debuggers - request for information email@example.com (David Keppel) (1995-08-01)|
|From:||R.Sosic@cit.gu.edu.au (Rok Sosic)|
|Keywords:||debug, design, report|
|Organization:||Griffith University, CIT|
|Date:||Fri, 21 Jul 1995 23:35:47 GMT|
firstname.lastname@example.org (Vern Paxson) writes:
] Arne Watnelie <email@example.com> wrote:
] > In the work with my master thesis, I have searched internet and libraries
] > for debugging related information, with little luck. Maybe I'm the only one
] > who don't manage to write correct programs? :-)
] > Any pointers to related information, either in books or on the internet,
] > would be very, very welcome.
] I also have a paper outlining a proposed agent-based debugger architecture,
] where the idea is that the debugger communicates with a (fairly simple)
] local agent linked into the debugged program. This has nice properties
] like giving you fast conditional breakpoints (because the agent can evaluate
] the breakpoint expression locally) and simple tele-debugging, and an
] architecture-independent debugger front end. The paper's not in any shape to
] distribute widely, but if you're interested drop me a line at firstname.lastname@example.org
] and I'll send you a copy.
Dynascope provides most of the functionality described above.
An announcement of the latest version of Dynascope, released
in April, follows.
Dynascope version 3.1.15 is available.
Dynascope home page:
Dynascope provides primitives for building directors. Directors are
programs which perform monitoring and debugging operations. Typical
such operations include controlling the execution of other programs,
sampling and modifying process data, and handling of breakpoints.
Dynascope primitives are simple to use and machine independent. They
provide directing in distributed and heterogeneous environments. Directors
and directed programs can execute on different computing platforms and
communicate over a network.
A director uses Dynascope primitives by calling directing routines. Because
these routines provide a machine independent procedural interface, directors
can be ported from one Dynascope supported computing platform to another
with no changes in their source code.
Directing primitives are classified in the following groups: process control,
process inquiries, state access, registers, breakpoints, tracing, dynamic
loading and linking, debugging information, and memory allocations.
The following platforms are supported in this release:
Nextstep 3.2 with M68K, SunOS 4.1.3 with SPARC V8 and IRIX 5.2 with R4000.
Comments, suggestions and error reports are welcome at:
Rok Sosic (email@example.com) _--_|\
School of Computing & Information Technology / GU
Griffith University, Nathan, QLD 4111, AUSTRALIA \_.--._/
phone: +61 7 875 5026; fax: + 61 7 875 5051 v
Return to the
Search the comp.compilers archives again.