<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'> > along with a special number for registers and pesudo-functions <BR> <BR>I missed that, sorry, by skimming.<br>Be sure to use very large but not negative numbers..as negative numbers<BR>might be actual offsets..<BR> <BR><br> > Beware module globals also. <BR> > I think they're rare enough that <BR> <BR><br>I disagree strongly. I'd really like to fix this too, at least put fields in the "segments" to give backends a chance...<br> <BR> <BR>Again, though, I don't want to change and recompile anything to debug.<br>Just like normal code.<br>If I'm going to recompile..well, then RTIO.PutText/printf/OutputDebugStringA/DbgPrint like crazy.<br>Sadly, I do a lot of that.<BR> <BR> <BR> <BR>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.<BR>There are tradeoffs either way.<BR>External files are the way on Windows and increasingly the way on Unix.<BR>But then you have to somehow find the file.<BR>"Internal" is great for ease of finding.<BR> <BR> <BR>Some systems (VMS) keep a minimal amount in the code, and I guess, the rest outside.<BR> <BR> <BR> <BR> > Recompile time is quick compared to the overhead this would introduce.<BR> <BR> <BR>The idea is to debug w/o source and compiler.<BR>But it is a slippery slope. Full "internal debugging" puts "almost" the source in the executable.<BR>Is source absent because it is secret? or large? Or always present?<BR> <BR> <BR> - Jay<br><br><br><br> <BR><div><div id="SkyDrivePlaceholder"></div><hr id="stopSpelling">Subject: Re: [M3devel] Internal debugging - a simple design<br>From: darko@darko.org<br>Date: Tue, 2 Apr 2013 15:54:41 -0700<br>CC: m3devel@elegosoft.com<br>To: jay.krell@cornell.edu<br><br><br><div><div>On Apr 2, 2013, at 3:39 PM, Jay K wrote:</div><br class="ecxApple-interchange-newline"><blockquote><span class="ecxApple-style-span" style="text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal; border-collapse: separate; orphans: 2; widows: 2;"><div class="ecxhmmessage" style="font-family: Calibri; font-size: 12pt;"><div dir="ltr">I don't want to have to recompile anything.<br>Ideally the overhead of the debug stuff is low enough that it is always on.<br>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.<br></div></div></span></blockquote><div><br></div><div>The constant debug information has to be stored somewhere, I guess it could be an external file to avoid increasing code size.</div><div><br></div><div><br></div><br><blockquote><span class="ecxApple-style-span" style="text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal; border-collapse: separate; orphans: 2; widows: 2;"><div class="ecxhmmessage" style="font-family: Calibri; font-size: 12pt;"><div dir="ltr"> I believe you need to make a function call for every line or "instruction".<br>That is the hook for stepping and breakpoints.<br></div></div></span></blockquote><div><br></div><div>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.</div><div><br></div><br><blockquote><span class="ecxApple-style-span" style="text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal; border-collapse: separate; orphans: 2; widows: 2;"><div class="ecxhmmessage" style="font-family: Calibri; font-size: 12pt;"><div dir="ltr"> You need function calls to the debugger for every assignment.<br>If you have something like "watch breakpoints"<br>("Break whenv variable x becomes 123.")</div></div></span></blockquote><blockquote><span class="ecxApple-style-span" style="text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal; border-collapse: separate; orphans: 2; widows: 2;"><div class="ecxhmmessage" style="font-family: Calibri; font-size: 12pt;"><div dir="ltr"> On the assignment matter though, it could be done in the step/instruction call.<br></div></div></span></blockquote><div><br></div><div>Again, if you want this you put a call in your code, just like the existing pragma.</div><div><br></div><div><br></div><br><blockquote><span class="ecxApple-style-span" style="text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal; border-collapse: separate; orphans: 2; widows: 2;"><div class="ecxhmmessage" style="font-family: Calibri; font-size: 12pt;"><div dir="ltr">There isn't necessarily a zero offset for parameters and locals..<br>well..a debug system probably creates one..homing all the parameters<br>and not enregistering everything..<br>You should probably bundle up the data into a smaller number of linked structures,<br>in order to pass fewer parameters to DebugProcEntry.<br></div></div></span></blockquote><div><br></div><div><br></div><div>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?</div><div><br></div><br><blockquote><span class="ecxApple-style-span" style="text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal; border-collapse: separate; orphans: 2; widows: 2;"><div class="ecxhmmessage" style="font-family: Calibri; font-size: 12pt;"><div dir="ltr"> <br> <br>Beware module globals also.<br>Even in my upcoming C backend work, they don't work well.<span class="ecxApple-converted-space"> </span><br>I think that needs frontend work. :(<br> <br></div></div></span></blockquote><div><br></div><div><br></div><div>I think they're rare enough that they could be handled with functions instead of this debugging code.</div><div><br></div><div><br></div><br><blockquote><span class="ecxApple-style-span" style="text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal; border-collapse: separate; orphans: 2; widows: 2;"><div class="ecxhmmessage" style="font-family: Calibri; font-size: 12pt;"><div dir="ltr"><br> - Jay<br><br><br><br> <br><div><div id="ecxSkyDrivePlaceholder"></div>> From:<span class="ecxApple-converted-space"> </span><a href="mailto:darko@darko.org">darko@darko.org</a><br>> Date: Tue, 2 Apr 2013 10:51:48 -0700<br>> To:<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> Subject: [M3devel] Internal debugging - a simple design<br>><span class="ecxApple-converted-space"> </span><br>> Here's an idea for how simple internal debugging might work.<br>><span class="ecxApple-converted-space"> </span><br>> 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.<br>><span class="ecxApple-converted-space"> </span><br>> For each procedure within a debugging scope the following declaration is inserted (the offsets are byte offsets):<br>><span class="ecxApple-converted-space"> </span><br>> CONST<br>> ProcName: TEXT = "Module.ProcName";<br>> ProcType: CARDINAL = 12345678;<br>> ProcAdr: ADDRESS = 123456;<br>> ParamNames = ARRAY OF TEXT{"param1", "param2", "param3"};<br>> ParamTypes = ARRAY OF CARDINAL{1, 2, 3};<br>> ParamOffs = ARRAY OF INTEGER{0, 4, 8, 16);<br>> ReturnType: CARDINAL = 12345678;<br>> ReturnOffs: INTEGER = 32;<br>> LocalNames = ARRAY OF TEXT{"local1", "local2", "local3"};<br>> LocalTypes = ARRAY OF CARDINAL{1, 2, 3};<br>> LocalOffs = ARRAY OF INTEGER{20, 24, 28, 36);<br>><span class="ecxApple-converted-space"> </span><br>> 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:<br>><span class="ecxApple-converted-space"> </span><br>> PROCEDURE DebugProcEntry(<br>> READONLY frame: ADDRESS;<br>> READONLY procName: ProcName;<br>> READONLY procType: ProcType;<br>> READONLY procAdr: ProcAdr;<br>> READONLY paramNames: ParamNames;<br>> READONLY paramTypes: ParamTypes;<br>> READONLY paramOffs: ParamOffs;<br>> READONLY returnType: ReturnType;<br>> READONLY returnOffs: ReturnOffs;<br>> READONLY localNames: LocalNames;<br>> READONLY localTypes: LocalTypes;<br>> READONLY localOffs: LocalOffs<br>> );<br>><span class="ecxApple-converted-space"> </span><br>> Whenever a procedure returns a procedure called DebugProcExit is called just before it exits, with the same parameters as DebugProcEntry.<br>><span class="ecxApple-converted-space"> </span><br>> - Darko<br>><span class="ecxApple-converted-space"> </span><br></div></div></div></span></blockquote></div><br></div> </div></body>
</html>