Difference between revisions of "EiffelDebugger"
(→Overview) |
|||
| (18 intermediate revisions by 4 users not shown) | |||
| Line 7: | Line 7: | ||
= Work in progress = | = Work in progress = | ||
| + | == Documentation == | ||
| + | * [[Inside the Eiffel Debugger]] | ||
| + | * [[ExecutionRecordAndReplay|Execution recording and Replay mechanism]] | ||
| + | |||
== Current == | == Current == | ||
* Building this wiki page, with list of suggested features. | * Building this wiki page, with list of suggested features. | ||
| − | |||
| − | |||
| − | |||
== Done == | == Done == | ||
* Improve the role of estudio/ec(ewb)/debugger/application | * Improve the role of estudio/ec(ewb)/debugger/application | ||
Now '''estudio''' is only an '''ec''' launcher | Now '''estudio''' is only an '''ec''' launcher | ||
| − | '''ec''' contains the classic eiffel debugger (ewb) and when needed launch the eiffel debugger daemon '''ecdbgd'' | + | '''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''' | The eiffel classic debugger daemon '''ecdbgd''' launches and control the debuggee '''application''' | ||
There is no more need for ebench lib and other linking particularities. | 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. | 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. | 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 = | = Suggestions = | ||
| Line 27: | Line 34: | ||
There is no order for now. | There is no order for now. | ||
| − | * being able to set/modify an env variable for an execution, aka "Edit and continue" feature | + | * '''DONE''' - being able to set/modify an env variable for an execution, aka "Edit and continue" feature |
* Being able to Attach/Detach Eiffel process | * Being able to Attach/Detach Eiffel process | ||
| + | * '''DONE''' - being able to evaluate a method | ||
* Add functionalities on Breakpoint | * Add functionalities on Breakpoint | ||
** tracepoint: output message when a stop point is reached | ** tracepoint: output message when a stop point is reached | ||
** changepoint: stop when a value changed | ** changepoint: stop when a value changed | ||
* include direct variable values in exception trace | * 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 | * Add tooltip on editor to show value of "pointed" variable | ||
* Being able to abort an expression evaluation | * Being able to abort an expression evaluation | ||
| Line 43: | Line 50: | ||
* Ctrl-C on STRING object tool's tree should copy the whole string | * 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 | For now, it copy the value displayed in the debugger's grid | ||
| − | * Improve the expanded display, to be more like Debug Viewer (like VS2005) | + | * '''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 | To be able to display XML data as XML, and so on | ||
* When an assertion fails need option to ignore it and continue | * 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 == | == Please add your suggestions below == | ||
(this way it is easier for persons working on the debugger to notice new suggestions) | (this way it is easier for persons working on the debugger to notice new suggestions) | ||
... Add your suggestions here ... | ... 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 = | = Current known limitations = | ||
Latest revision as of 05:29, 28 May 2008
This page is about the Eiffel debugging facilities integrated inside Eiffel Studio
Contents
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.
