Re: debuggers

buzzard writes
> It might be worth considering giving some compiler support to doing soft
> data watchpoints, by providing extra debug information to support this
> scenario:
>
> Rather than single stepping every instruction executed, and checking the
> location, the debugger can:
>
> 1. single step conditional flow-control operations
> 2. put breakpoints after the next instruction that writes to memory


I see no reason you need to embellish the symbol table to accomplish this
for most machines. Parsing instructions for a RISC machine is pretty
trivial. To be reasonable, the debugger would have to cache the results of
parsing. (This assumes some faster way of reading the debugging target's
address space than a single word read via ptrace. It also has the
advantage of not making the executable larger and slowing down the compile
when I'm not using watchpoints.)


> Using these two is sufficient to reducing the number of single-step
> operations to (effectively) the number of conditional branches and memory
> writes, which I'd expect to be about an order of magnitude better.


In extreme cases. Conventional wisdom is that programs branch every five
instructions or so. Adding in every store, I expect a factor of two or
three is optimistic for many codes.


However, a smart debugger could eliminate lots of the writes and do a
certain amount of branch prediction. For example, stores to stack locals
will not hit the heap unless the stack pointer is trashed. Most
instructions don't modify the stack pointer, so for many functions, the
debugger could eliminate all stack pointer relative stores with a single
stack pointer check. (For architectures which push and pop arguments, the
maximum stack depth can be calculated and checked at function entry, and
probably after each function call returns.) For simple loops, the debugger
could do the reverse of induction variable optimization to figure out if a
pointer you're storing through ever points to a watched address.


All this said, I probably don't want that complexity in a debugger. The
main things I want in a debugger are reliability and speed. If the
debugger ever lies to me about variable values or program location, it's
basically worse than useless. If simple operations take more than about 10
seconds, my debugging process gets messed up because I forget one or two
of the five possible bug causes I'm looking for.


Dealing with broken symbolic debuggers has taught me to appreciate fine
tools like Macsbug and TMON (low-level 68K assembly language debuggers for
the Macintosh). (And even adb, though its user interfaces is atrocious.)
--
Zalman Stern zalman@adobe.com (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
--

Return to the comp.compilers page.
Search the comp.compilers archives again.