EiffelDebugger


This page is about the Eiffel debugging facilities integrated inside Eiffel Studio

Overview

Work in progress

Documentation

Current

  • Building this wiki page, with list of suggested features.


Done

  • Improve the role of estudio/ec(ewb)/debugger/application
Now estudio is only an ec launcher
ec contains the classic eiffel debugger (ewb) and when needed launch the eiffel debugger daemon ecdbgd
The eiffel classic debugger daemon ecdbgd launches and control the debuggee application
There is no more need for ebench lib and other linking particularities. 
Now thr workbench ec is able to debug and to be debugged at the same time. 
This helps a lot improving the classic eiffel debugger.

Don't forget, you can (now) always start the graphical EiffelStudio using ec -gui
estudio is doing more or less this, it just hide the text console, provide a splash screen
and allow various customization, but it is just an easy launcher for EiffelStudio ec -gui
  • Provide a way to pass environmental variables values to the debuggee

Suggestions

Here is a list of features we could think of, or suggested by Eiffel Studio users. There is no order for now.

  • DONE - being able to set/modify an env variable for an execution, aka "Edit and continue" feature
  • Being able to Attach/Detach Eiffel process
  • DONE - being able to evaluate a method
  • Add functionalities on Breakpoint
    • tracepoint: output message when a stop point is reached
    • changepoint: stop when a value changed
  • include direct variable values in exception trace
  • DONE - Add an "auto values" panel (similar to watches point, but using the current feature/line to show "near" variables values
  • Add tooltip on editor to show value of "pointed" variable
  • Being able to abort an expression evaluation
On dotnet there is a timeout, if the expression is taking too long, but for now nothing similar on classic
  • having named group of breakpoints, this could enable use to Enable/Disable groups of breakpoints
  • auto save Breakpoints more often
Currently, the breakpoints are saved after : end of debugging session, end of compilation, end of Eiffel Studio session
  • Ctrl-C on STRING object tool's tree should copy the whole string
For now, it copy the value displayed in the debugger's grid
  • DONE - Improve the expanded display, to be more like Debug Viewer (like VS2005)
To be able to display XML data as XML, and so on
  • When an assertion fails need option to ignore it and continue
  • merge call stack tool with threads tool using a tree_enabled grid

Please add your suggestions below

(this way it is easier for persons working on the debugger to notice new suggestions) ... Add your suggestions here ...

  • Allow old syntax in the watch tool or put all old evaluations in the Object tool. This way, if we have a postcondition that goes "index = old index + 1" and it gets violated, it's possible to see the old value of index to better understand the cause of the assertion violation.
  • Allow step-by-step execution of the invariants evaluation.
  • Object viewer for HASH_TABLE.

Crazy Brainstorms

  • A way to mark already executed lines with a different background, so when you are debugging a large feature (a typical example is a feature with nested if-then-else), you'll know the execution context (i.e., which branches were executed). For loops, we can use 2 different background colors, one for the current iteration, the other for former iterations. To implement this, we need to have some sort of callbacks every time when we meet the starting slot of a branch, such as if, else, inspect. From this along with the current execution point, we can infer which lines were actually executed. We only need to keep the information of the slots that are in current call stack. A way to achieve this is by generating invisible breakpoints, i.e., breakpoints that not visible to programmers, they are just used to record information. All the marked lines together provides a dynamic slicing of the running program. But this (I mean, only record branch start slots) is just for optimization. It lacks of generality. Because if we have callbacks for every slot, we can provide a event-based programmable debugger interface.


  • Difficulty in debugging is the exact reason why general best practice is to write small discrete methods. I would recommend replacing your inner loops with a method call that contains the inner loop. Most people are worried about the "performance hit" of this, but in reality there is 0 performance hit because the *compiler* will inline it. Human readable code, translated by the compiler, to efficient machine code.

Current known limitations

Retrieved from "https://dev.eiffel.com/index.php?title=EiffelDebugger&oldid=11122"