Re: Ok sorry, it is just a book gives no feedback.

[Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)]

In article <3A59B1E1.A46DBE47@acm.org>, Marin David Condic <mcondic.nospam@acm.org> writes:
> Larry Kilgallen wrote:
> 
>> Been there, done that, got the T-shirt.  I detested it.
>> I think one of the great debugger advances has been to
>> use a small engine in the process being debugged and
>> put the great bulk of the debugger (GUI, etc.) into
>> another process where it will not impact addresses,
>> etc.  (Of course that does not eliminate the heisenbug
> 
> I am presuming that you are talking about having a relatively small chunk of code in an
> embedded app that will grab the contents of memory and send it down the wire upon request,
> etc.? The concept of an on-board monitor that will load & read memory, maintain lists of
> addresses to watch & report on periodically, etc. has been around for a while. They work very
> nicely - especially since they remain in the production code/box so that you can actually use
> them in the field if necessary. You don't need any special equipment besides the presence of
> a communication link.

Actually, my own concerns are more within a single general-purpose operating
system where one wants a full GUI debugger interface run by one process and
debugging another process.

My other application, closer to yours, is for debugging kernel code on a
general-purpose operating system with a separate system handling the GUI
for the debugger.

While the same approaches work for me as for you embedded folks, I post
this reply to emphasize the diversity of interests in the newsgroup.

==============================================================================
Great Inventors of our time: Al Gore -> Internet; Sun Microsystems -> Clusters
==============================================================================