I am thinking of an interactive GUI based debug/monitor kind
of tool for Felix and solicit ideas and comments.
>From the compiler viewpoint, the idea is a special statement
something like
`BEXE_debug (sr,"comment")
This will generate a macro like:
EMIT_DEBUG(c++ src loc, felix src loc, "comment")
By default the macro is defined to nothing, however it
can be enable by a compilation option to call a C function
emit_debug(....)
This function then picks up some global variables such as:
bool debugging_on = false;
HANDLE debug_socket = 0;
and writes information to the socket if debugging is on
and the socket is set (we might have an option here
for a file descriptor instead .. they're different
on Windows).
Now, for the driver viewpoint it gets more fun. With an appropriate
switch, the driver starts a server which can accept a monitor
connection. The monitor client can send commands to the server,
and the server can take actions or reply. Some commands might be:
KILL -- just abort the process
STOP -- lock up the Felix threads when they next
do a supervisor request (SVC)
RUN -- restart a STOPped process
DUMP -- print out the current heap
TRACE -- switch on EMIT_DEBUG tracing
UNTRACE -- switch off EMIT_DEBUG tracing
GCSTATS -- print gc stats
GCSET -- set gc profile parameters
The monitor client can have several windows. One is a standard
telnet style window for issuing commands above.
Another window can actually show the currently executing
Felix code with the line being executed highlighted,
another could even show the corresponding C++ code.
The client could also accumulate a list of all executed
lines, which provides coverage data, and count them,
which provides profiling data.
The emit protocol could have some variations. For example
in real time mode, it doesn't block and ignores buffer
overflow, and the client just does the best it can to
keep the GUI going.
In step mode, the program handshakes with the client,
so the GUI shows each step, even if it slows the program down.
By 'failing' to handshake for a while, you can actually pause
the program.
The protocol should also handle multiple threads, perhaps
EMIT will put out a thread id, and probably also a time stamp.
This would allow one window for each thread.
With appropriate instrumentation, eg "ENTRY fun f",
"LEAVE fun f" the execution stack could also be shown ..
dynamically.
With some fiddling .. all this can be done and STILL
run the process under a machine code debugger like gdb
or Visual Studio -- however now we have additional
high level information and control such a debugger
will never provide.
Finally .. some information can be provided EVEN WITHOUT
INSTRUMENTATION. To see this right now, just run with --debug!
Heap allocations and deallocations print, and it even
shows the data type involved .. because a heap allocation
requires a shape object.
In fact it is possible to trace procedure call/return
without generating any instrumentation .. since that
is handled by yielding to the driver .. the only
trick is that some procedures get stack allocated,
so we'd need a hack to tell if the proc was on the
stack or heap before trying to get at its RTTI
(stacked frames don't have any RTTI).
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
