[M3devel] Internal debugging - a simple design

[Darko]

On Apr 2, 2013, at 3:39 PM, Jay K wrote:

> I don't want to have to recompile anything.
> Ideally the overhead of the debug stuff is low enough that it is always on.
> That is difficult. Or maybe everything is so fast these days that we can just be inefficient. Nobody noticed how bad cm3cg's codegen was, after all, or that it got better.

The constant debug information has to be stored somewhere, I guess it could be an external file to avoid increasing code size.



>  I believe you need to make a function call for every line or "instruction".
> That is the hook for stepping and breakpoints.

I don't think this is required. If you want to break you put in a call in your code. Recompile time is quick compared to the overhead this would introduce.


>  You need function calls to the debugger for every assignment.
> If you have something like "watch breakpoints"
> ("Break whenv variable x becomes 123.")
>  On the assignment matter though, it could be done in the step/instruction call.

Again, if you want this you put a call in your code, just like the existing pragma.



> There isn't necessarily a zero offset for parameters and locals..
> well..a debug system probably creates one..homing all the parameters
> and not enregistering everything..
> You should probably bundle up the data into a smaller number of linked structures,
> in order to pass fewer parameters to DebugProcEntry.


Notice the offset is an integer, along with a special number for registers and pesudo-functions to access them, wouldn't that avoid changes for debugging?


>  
>  
> Beware module globals also.
> Even in my upcoming C backend work, they don't work well. 
> I think that needs frontend work. :(
>  


I think they're rare enough that they could be handled with functions instead of this debugging code.



> 
>  - Jay
> 
> 
> 
>  
> > From: darko at darko.org
> > Date: Tue, 2 Apr 2013 10:51:48 -0700
> > To: m3devel at elegosoft.com
> > Subject: [M3devel] Internal debugging - a simple design
> > 
> > Here's an idea for how simple internal debugging might work.
> > 
> > A command line option is created that turns on debug code generation globally. A pragma is created, <*DEBUG*> which turns on debugging for all of the procedures within the scope that the pragma precedes, being an implementation module or a possibly nested procedure. Both must be done for debugging code to actually be generated for a procedure.
> > 
> > For each procedure within a debugging scope the following declaration is inserted (the offsets are byte offsets):
> > 
> > CONST
> > ProcName: TEXT = "Module.ProcName";
> > ProcType: CARDINAL = 12345678;
> > ProcAdr: ADDRESS = 123456;
> > ParamNames = ARRAY OF TEXT{"param1", "param2", "param3"};
> > ParamTypes = ARRAY OF CARDINAL{1, 2, 3};
> > ParamOffs = ARRAY OF INTEGER{0, 4, 8, 16);
> > ReturnType: CARDINAL = 12345678;
> > ReturnOffs: INTEGER = 32;
> > LocalNames = ARRAY OF TEXT{"local1", "local2", "local3"};
> > LocalTypes = ARRAY OF CARDINAL{1, 2, 3};
> > LocalOffs = ARRAY OF INTEGER{20, 24, 28, 36);
> > 
> > Extra calls are inserted into a procedure within a debugging scope so that whenever the procedure is called DebugProcEntry is called first. DebugProcEntry must be declared or imported in the procedure's module. DebugProcEntry passes all the above constant declarations as parameters, plus an extra parameter which gives the address of the zero offset for the parameters and local variables:
> > 
> > PROCEDURE DebugProcEntry(
> > READONLY frame: ADDRESS;
> > READONLY procName: ProcName;
> > READONLY procType: ProcType;
> > READONLY procAdr: ProcAdr;
> > READONLY paramNames: ParamNames;
> > READONLY paramTypes: ParamTypes;
> > READONLY paramOffs: ParamOffs;
> > READONLY returnType: ReturnType;
> > READONLY returnOffs: ReturnOffs;
> > READONLY localNames: LocalNames;
> > READONLY localTypes: LocalTypes;
> > READONLY localOffs: LocalOffs
> > );
> > 
> > Whenever a procedure returns a procedure called DebugProcExit is called just before it exits, with the same parameters as DebugProcEntry.
> > 
> > - Darko
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130402/00df58d6/attachment-0001.html>