Re: [gobo-eiffel-develop] GEC debugger requirements

[Wolfgang J. <wj...@so...>]

Howard Thomson wrote:
> Hi Paul,
>
> I am working on EDP, an IDE based on the Gobo tools and the infrastructure 
> used to build GEC, and have also been thinking about how to debug, trace, 
> probe, etc an executing Eiffel system.
>
> As the intricacies of inter-process debugging are so arcane and (in my 
> opinion) poorly documented, and of course totally incompatible between Linux 
> and Win32, I am intending that debugging be done in-process.
>
> That is, the Eiffel system will be built with at least two threads, the 
> initial program entry point and first thread being a (possibly gui front 
> ended) debug and monitor thread which creates a second thread which starts in 
> the debugged system's root class and creation routine.
>
> The primary difficulty with such a system is the interaction with the C 
> runtime library and the aspects of a process that are process-wide rather 
> than thread specific, such as file handles (!).
>
> As in SE, debug generated code will have code that updates the current stack 
> frame with the POSITION of the about-to-be-executed INSTRUCTION, and code to 
> test for thread-suspension etc.
>
> A posting was recently made about some code to do something similar, 
> previously implemented for SE, which may be adaptable.
>   
Yes, see below.
> But first, I need some thread building blocks to work on.
>
> I am currently working towards making EDP compilable by EiffelStudio at which 
> point I can refer to it from EiffelRoom and start to get other people 
> interested (possibly !).
>
> Are you doing any development work yourself ?
>
> Regards,
>
> Howard
>
> On Wednesday 08 August 2007 22:20, Paul Cohen wrote:
>   
>> Hi all,
>>
>> I am not an expert in writing compilers or debuggers but I would like
>> to propose a list of requirements for the GEC debugger.
>>
>> I have rated the requirements with a two graded priority scale
>> indicated by the presence of a '*'. Any requirement marked with a '*'
>> I consider lower priority. Of course, eventually I would like all
>> requirements to be implemented! ;-)
>>
>> 1. Assumptions
>> ------------------------
>>
>> 1.1 GEC can be run with some debug flag enabling the compiled program
>> to be run by the GEC debugger,
>> 1.2 The GEC debugger has a nice name or acronym like "gedb" so that I
>> don't have to write "GEC debugger" all the time!
>>
>> 2. General requirements
>> --------------------------------------
>>
>> 2,1 Command line debugger in gdb style.
>> 2.2 Default execution mode is interactive.
>> 2.3 Switch for telling which executable to load.
>> 2.4* Switch for running in batch mode. When running in batch mode a
>> file (or stdin) containing debugger commands is read and the debugger
>> executes the
>> commands in straight sequence as if they had been manually entered in
>> interactive mode.
>>
>> 3. Debugger commands
>> -------------------------------------
>>
>> Commands are run by entering them on the gedb prompt. Commands that
>> take arguments have the arguments enclosed in brackets '['  and ']'.
>> Commands should have abbreviated short forms like 'r' for run etc.
>>
>> 3.1 Help. Print info on available commands.
>> 3.2 Run.
>> 3.3 Single step to next execution point.
>> 3.4 Step over to next execution point in current feature.
>> 3.5 Step out of current feature.
>> 3.6 Show info on loaded executable (compile time, compile flags etc.).
>> 3.7 Show stack.
>> 3.8 Show Eiffel text [lines] of n lines surrounding current execution
>> point. 3.9 Show locals.
>> 3.10 Show object [id] (current object if id not given).
>> 3.11 Quit.
>> 3.12 Set breakpoint [class.feature name and line no]. If no
>> class.feature name and line no is given, set breakpoint at current
>> execution point.
>> 3.13 Show breakpoints (together with unique breakpoint id:s).
>> 3.14 Delete breakpoint [breakpoint id].
>> 3.15 Save breakpoints to file.
>> 3.16 Load breakpoints from file.
>> 3.17 Terminate execution.
>> 3.18* Stop execution. Not a proper command, but some way to generate
>> an interrupt and stop the current execution (at some execution point
>> after which one can continue step debugging the program).
>> 3.19* Edit local entity [name and value].
>> 3.20* Edit object [id] [attribute/once name, value]. (current object if no
>> id) 3.21* Set conditional breakpoint [class.feature name and line no]. If
>> no class.feature name and line no is given, set breakpoint at current
>> execution point. A new prompt is displayed where the condition can be
>> expressed.
>> 3.22* Show object info [type/class]. Show number of objects of a given
>> type (or class) together with other interesting info. If no type/class
>> is given show summary stats for all objects in executed system.
>> 3.23* Show GC info. Show number of objects that have been garbage
>> collected and other exciting GC info.
>>
>> /Paul
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >>  http://get.splunk.com/
>> _______________________________________________
>> gobo-eiffel-develop mailing list
>> gob...@li...
>> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>>     
Two or three weeks ago I offered to add (mutatis mutandis)
to GEC the debugger I developed for SE.
The debugger is one of three possible additions.
The others are introspection and persistence closure.
Debugger and persistence closure depend on introspection,
and currently I'm still trying to add introspection.
In other words, adding the debugger will be not done
today or tomorrow.

Which of your requirements are already satisfied?
- Not 1.* and 2.* since the debugger is not separate from
the debuggee (a situation like the SE debugger).
To satisfy the requirements needs much more
development and, as I think, has not the highest priority.
- 3.1 to 3.14, 3.17, 3.18, 3.21,3.22 are available;
- 3.15, 3.16 are not hard to implement. Whether
to implement 3.19, 3.20 is a question of philosophy.

While not all of your requirements are satisfied,
some of the already implemented debugger commands
go far beyond, e.g. evaluation of not merely object values
but arbitrary expressions (which may include function calls)
and accompanying breakpoints with more sophisticated
conditions than just "class.feature name and line no".

WJ

PS:
The user's guide of the SE debugger.

-- 
Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...