gobo-eiffel-develop

[gobo-eiffel-develop] GEC debugger requirements

[Paul C. <pac...@gm...>]

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

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 

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...

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

[Paul C. <pac...@gm...>]

On 8/9/07, Howard Thomson <how...@di...> wrote:
> 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.

I am strongly in favour of a CLI-based debugger. GUI frontends can
later be added. Actually I would write a debugger API (.dll/.so) to
ensure that any type of UI can be added later.

> Are you doing any development work yourself ?

Not in Gobo. Due to my personal situation I just don't have that much
time for spare time projects.

On 8/9/07, Wolfgang Jansen <wj...@so...> wrote:
> Two or three weeks ago I offered to add (mutatis mutandis)
> to GEC the debugger I developed for SE.

Yes that would indeed be a great addition!

> 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.

Ok.

> 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.

Ok. Couldn't batch mode (and reading commands from a file/stdin)
execution be implemented with not to much effort?

> - 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.

I don't quite understand what you mean by philosophy. Are you saying
that editing program data during debugging can be seen as violating
some debugging principle or? I see them rather as power debugging
features.

> 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".

Excellent.

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

Thanks for the (obvoius) tip1 :-) I haven't used SmartEiffel for some years now.

I would like to underline that my initial posting was intended to
serve as input for you and others, like Howard who are interested in
and have time and competence to develop a Gobo debugger.

I would very much like to participate, but I don't have any experience
in writing either compilers or debuggers and more importantly I don't
have the spare time to learn or invest in this now. I will however
really try to find time to test the debugger and discuss requirements
from the perspective of a user.

/Paul

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

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

Paul Cohen wrote:
> On 8/9/07, Howard Thomson <how...@di...> wrote:
>   
>> 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.
>>     
>
> I am strongly in favour of a CLI-based debugger. GUI frontends can
> later be added. Actually I would write a debugger API (.dll/.so) to
> ensure that any type of UI can be added later.
>
>   
>> Are you doing any development work yourself ?
>>     
>
> Not in Gobo. Due to my personal situation I just don't have that much
> time for spare time projects.
>
> On 8/9/07, Wolfgang Jansen <wj...@so...> wrote:
>   
>> Two or three weeks ago I offered to add (mutatis mutandis)
>> to GEC the debugger I developed for SE.
>>     
>
> Yes that would indeed be a great addition!
>
>   
>> 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.
>>     
>
> Ok.
>
>   
>> 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.
>>     
>
> Ok. Couldn't batch mode (and reading commands from a file/stdin)
> execution be implemented with not to much effort?
>   
The debugger is CLI-based. Thus, interactive mode and batch mode
by reading commands from stdin (and then from an arbitrary file)
is not very different. The necessary changes/additions include
- suppressing command prompts
- redirecting debugger output to a file
- stop after command error
There is no problem to make the changes/additions.

But is batch mode really of interest? To my experience, 
debugging will be done if the program does not what was expected,
i.e. if there is a somewhat surprising outcome.
Interactive mode is needed to react to unexpected behavior.
>   
>> - 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.
>>     
>
> I don't quite understand what you mean by philosophy. Are you saying
> that editing program data during debugging can be seen as violating
> some debugging principle or? I see them rather as power debugging
> features.
>   
Yes, philosophy means here that some people do not like to change
program data during debugging. A viable approach in case of Eiffel
may be as follows: changing an attribute value is allowed if the class
of the enclosing object has been compiled with invariant checking on
and if the invariant is still satisfied after the change.
There will be no restriction to change local variables.
But what about routine arguments? The program must not change them,
will the debugger be allowed to do so? (This is a secondary problem
and may be discussed later.)

In any case, the necessary actions (obtaining the new value as evaluation
of an expression, obtaining the variable's address, evaluating the class 
invariant)
have already been implemented as by-products of other commands.
>   
>> 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".
>>     
>
> Excellent.
>
>   
>> PS:
>> The user's guide of the SE debugger.
>>     
>
> Thanks for the (obvoius) tip1 :-) I haven't used SmartEiffel for some years now.
>   
I hope that you didn't misunderstand the role that the debugger
plays in SE: it is not part of the official SE distribution.
I made the offer to SE1.2 developers to add it to this
compiler version, but I didn't get any answer so far.
> I would like to underline that my initial posting was intended to
> serve as input for you and others, like Howard who are interested in
> and have time and competence to develop a Gobo debugger.
>
> I would very much like to participate, but I don't have any experience
> in writing either compilers or debuggers and more importantly I don't
> have the spare time to learn or invest in this now. I will however
> really try to find time to test the debugger and discuss requirements
> from the perspective of a user.
>
> /Paul
>
>
>   


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

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

[Paul C. <pac...@gm...>]

On 8/10/07, Wolfgang Jansen <wj...@so...> wrote:
> Paul Cohen wrote:
> > Ok. Couldn't batch mode (and reading commands from a file/stdin)
> > execution be implemented with not to much effort?
> >
> The debugger is CLI-based. Thus, interactive mode and batch mode
> by reading commands from stdin (and then from an arbitrary file)
> is not very different. The necessary changes/additions include
> - suppressing command prompts
> - redirecting debugger output to a file
> - stop after command error
> There is no problem to make the changes/additions.
>
> But is batch mode really of interest? To my experience,
> debugging will be done if the program does not what was expected,
> i.e. if there is a somewhat surprising outcome.
> Interactive mode is needed to react to unexpected behavior.

Debugging Eiffel wrappings of C code or problems with using C API:s
can be quite tricky at times. I have had cases where it would have
been nice to be able to quickly rerun a debugging session to see if I
get the same behaviour or not, without having to add debug trace
statements to the program. But you are right that having a CLI allows
you to give the debugger commands from stdin. Which is one of the many
benefits of having a CLI-based debugger!

> >
> >> - 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.
> >>
> >
> > I don't quite understand what you mean by philosophy. Are you saying
> > that editing program data during debugging can be seen as violating
> > some debugging principle or? I see them rather as power debugging
> > features.
> >
> Yes, philosophy means here that some people do not like to change
> program data during debugging.

Ok. I think I'm more pragmatic in this case.

> A viable approach in case of Eiffel
> may be as follows: changing an attribute value is allowed if the class
> of the enclosing object has been compiled with invariant checking on
> and if the invariant is still satisfied after the change.

Yes. That seems reasonable.

> There will be no restriction to change local variables.
> But what about routine arguments? The program must not change them,
> will the debugger be allowed to do so? (This is a secondary problem
> and may be discussed later.)
>

Ok. Obviously there are some issues that need to be resolved/decided
regarding the requirements on data editing. That is to say, if data
editing commands are to be added to the debugger at all. That is the
reason I listed those requirements as lower priority for now.

> I hope that you didn't misunderstand the role that the debugger
> plays in SE: it is not part of the official SE distribution.
> I made the offer to SE1.2 developers to add it to this
> compiler version, but I didn't get any answer so far.

I see. As I said before, I would welcome your debugger contribution to
Gobo very much!

/Paul