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

[Robert Dewar <robert_dewar@my-deja.com>]

In article <z4W1k714y7z3@eisner.decus.org>,
  Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:
> Are there many such debuggers still in use for major
> operating systems ?  I remember something called ODT (Octal
> Debugging Tool) for the PDP-8, but I think a lot of people do
> not even remember the PDP-8.

You miss my point, I am not talking about symbolic debugging,
but cases where elaborate logic is required for detecting and
logging an error situation. I know of no debuggers where it is
easy to program complex functions that operate comfortably
within the target environment.

For example, suppose you have logic which expects that a
certain number should always satisfy certain constraints,
due to logic in the program. You suspect that at some point,
you have a value that does not meet these constraints.
Basically what you want to add is a check to see if these
conditions are met (arbitrarily complex code), and if they
are not met, dump out various complex information at a high
level of abstraction. This is not a task that is within reach
of typical debuggers!

I find that people who "detest" certain styles of working and
working environments sometimes lack the flexibility to deal
with difficult situations. It sounds for instance like you
would be really stuck if you were in a hiesenbug situation
where the bug does not appear if you operate in the presence
of the debugger. This can most certainly happen with some kinds
of erroneous programs, or where timing problems are an issue.

Indeed in real time programs, the paradigm of breakpoint and
examine often breaks down badly. Yes, there are some
asyncrhonous debugging tools around (like OCS Aprobe) which
can be very valuable in such situations, but sometimes, a
judiciously placed put_line can be the most efficient and
effective debugging approach. If you are sure you "detest"
such an approach, you may end up proceeding in less than
an optimal manner. Flexibility is always a plus.

Note that when using GDB, there is a very useful hybrid
approach that is often very attractive, which is to write
debugging routines that output information in a suitable
high level abstract form (see for example the pn routine
in GNAT for printing an AST node). Then the routine is
called from the debugger. For example, when we are debugging
the GNAT compiler itself, we write as a gdb command:

  pn (125)

and this prints the contents of node 125 in a high level
symbolic form.

But this capability requires that the debugging routines be
able to do output, so you run into the same Pure/Preelaborable
situations.

Larry, I take it you are still stuck in an Ada 83 environment,
where this particular issue does not arise? (I say that because
it is quite a familiar problem to Ada 95 programmers :-)

Robert


Sent via Deja.com
http://www.deja.com/