[M3devel] Internal debugging - a simple design

[Jay K]

 > along with a special number for registers and pesudo-functions  I missed that, sorry, by skimming.
Be sure to use very large but not negative numbers..as negative numbersmight be actual offsets.. 
  > Beware module globals also.   > I think they're rare enough that   
I disagree strongly. I'd really like to fix this too, at least put fields in the "segments" to give backends a chance...
  Again, though, I don't want to change and recompile anything to debug.
Just like normal code.
If I'm going to recompile..well, then RTIO.PutText/printf/OutputDebugStringA/DbgPrint like crazy.
Sadly, I do a lot of that.   Other than an external file, compilers have support for "sections" -- you can put the "cold" code/data "out of the way", but in the same file.There are tradeoffs either way.External files are the way on Windows and increasingly the way on Unix.But then you have to somehow find the file."Internal" is great for ease of finding.  Some systems (VMS) keep a minimal amount in the code, and I guess, the rest outside.    > Recompile time is quick compared to the overhead this would introduce.  The idea is to debug w/o source and compiler.But it is a slippery slope. Full "internal debugging" puts "almost" the source in the executable.Is source absent because it is secret? or large? Or always present?   - Jay



 Subject: Re: [M3devel] Internal debugging - a simple design
From: darko at darko.org
Date: Tue, 2 Apr 2013 15:54:41 -0700
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu


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/20130403/39d786b9/attachment-0002.html>