GEC introspection & debugger

Hi,

long time ago I offered to provide code for introspection and
persistence closure to the GOBO library as well as a debugger
for then GEC. Work took more time than expected but now an
experimental version is available.


The following naming convention has been applied:

1) Introspection classes have prefix "IN_" and are located
in cluster $GOBO/library/intro.

2) Persistence classes have prefix "PC_" and are located
in cluster $GOBO/library/persist

3) Debugger classes have prefix "DG_" and are located
in cluster $GOBO/library/tools/eiffel/debugger

4) Special versions of introspection classes used
during compilation have prefix "ET_IN_" and are located
in cluster $GOBO/library/tools/eiffel/generation/intro

5) The generated C code contains additional
#defines, typedefs and global variables.
They all have the prefix "GE_Z" or "GE_z".
Of course, names and clusters may be changed.


Changes of existing classes and C code:

The additional C code necessary for introspection
and debugging (the persistence closure is a pure library
and does not need additional C code) is generated
in descendant classes of ET_C_GENERATOR which
belong to cluster $GOBO/library/tools/eiffel/generation.
There are just two changes in existing code:

1) Class GEC, lines 199... and 234...:
some local variables have been added and
      create l_generator.make (l_system)
is replaced by code that creates an object of the appropriate
descendant class.

2) Class ET_C_GENERATION:
- No-operation routine "print_extension" has been added
and is called near the end of routine "generate_c_code" (line 719).
- Code flushing has been moved from line 13162 to line 894.
- Line 1298 has been removed.

3) Class ET_DYNAMIC_SYSTEM:
- Second half of routine `compile_system' has been
separated as routine `compile_more' (called from
`compile_system' and new code).
- Attributes `added_type' and `added_procedure'
have been added (set by `compile_more').

4) Classes ET_AGENT and ET_DYNAMIC_FEATURE
have been made HASHABLE.

5) $GOBO/gec/runtime/c/ge_exception.[hc]:
A `typedef' has been added as well as code
to jump to the debugger in case of an exception
before unwinding the stack.

Other properties:

1) The implementation of the new classes follows the command/query
separation principle.

2) Accessing of the additional generated C code is done
by `external "C inline"' functions.
The C code has almost everywhere one effective line only.
But there may be more physical lines like:
#ifdef SOME_CONSTANT
  good_C_code
#else
  dummy_C_code
#endif

3) The implementation does not (not yet?) follow
all GOBO's style guidelines.


Some problems and open questions remain:

1) I detected a few errors in the compiler or the
generated C code. I will report them in a separate mail.

2) The compiler generates test for Void targets like
      return ((T1)(((T0*)(GE_void(a1)))->id==66));
      l6 = ((GE_void(l5), (T0*)0));
In most cases this is welcome but is counter-productive
in case of introspection, ... which generate references
from C pointers: the compiler is not aware of the objects
and often generates code where the references are
erroneously treated as `Void'.
For example, when restoring an object from file in independent
store mode its contents (i.e. whether attributes are void or not)
is beyond the scope of the actual system's compilation.
This means that objects and their attributes (recursively to any
depth) obtained from C pointers must be treated as potentially
void (i.e. generate Void-tests like the 1st example above)
but must also be treated as potentially not-void
(i.e. *not* code like the 2nd example).

3) To display more informative debuggee status the compiler
should collect more information. For example, some compiler
related classes have queries like `keyword: ET_KEYWORD'
which potentially provide a keyword's position in class text.
Unfortunately, the position is not always set.

4) There is one inconvenience when installing the new stuff.
Previously, installation of GEC consists of two compilations:
first by use of ISE, SE or an old GEC, second, by the GEC
just obtained. The inconvenience is that one more iteration
is necessary: compile GEC once more by itself.
Forthcoming installations do not need the extra compilation
as long as the structure of store files is not changed.

5) How can a user force the compiler to generate code for debugging?
Currently I apply the SE style: if option "trace(yes)" is set in
the ACE file then debugging code is generated (but no tracing code).
Another solution may be in order.

6) The most severe problem is how the debugger can be integrated
into a system. The problem is as follows. The debugger is written
in Eiffel (classes DG_DEBUGGER etc.) but the classes of the
debuggee are not aware of that class and DG_DEBUGGER would not
be compiled. The current solution is that after compiling the
debuggee a seemingly second system of root class DG_DEBUGGER
is compiled (therefore, the routine `compile_more')
and all is put into *one* C code.
The solution is rather tricky. How can this be managed better?


So, if you are interested, how should the new stuff be integrated
into the GOBO project?
Simply by updating via SVN? By a new SNV path (probably better
since the new stuff still in experimental state)? Another way?

Best regards
WJ

PS:
- The attachment contains the user's guide of the debugger.
- GOBO version used: GOBO39, SVN 6656

-- 
Dr. Wolfgang Jansen
University of Potsdam, Germany
mailto: [email protected]

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

_______________________________________________
gobo-eiffel-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop