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

[Howard T. <how...@di...>]

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.

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

-- 
Howard Thomson

--
"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former." -- Albert Einstein