<div dir="ltr">Hi Marc!<div><br></div><div>The following topic has been important since a long time. I think there are like 10 bumps in the mailing list on this one for many years.</div><div><br></div><div>Maybe it was bumped so many times on the ML that if you answered at some point I might even have missed that response. Now to get to the bottom with this:</div><div><br></div><div>Your complete response on this one would be very valuable.</div><div><br></div><div><br></div><div>Gambit debugging can regard both interpreted and compiled modes. There's intra-Gambit debugging (singlestepping, ,bt , pp etc.), and there's extra-Gambit debugging (GDB bt , core files, etc.).</div><div><br></div><div>Let's categorize the more subtle debugging options such as the "console" file output and any debug output in the memory subsystem etc. as extra-Gambit here too.</div><div><br></div><div><br></div><div>Gambit's intra-Gambit debugging of interpreted code is always enabled in the default distro.</div><div><br></div><div>The remainder of debugging functionality is off by default, and enabled by the --enable-debug option to ./configure .</div><div><br></div><div><br></div><div>--enable-debug unfortunately is a double edged sword, it will give you some nice debugging stuff - and it will crash your whole operating system given the "right" parameters, which are very easy to run into without in any way having aimed at them intentionally.</div><div><br></div><div><br></div><div>The things I am aware that --enable-debug does are:</div><div><br></div><div>1. It enables C-level debugging symbols, i.e. adds "-g" or the like to gcc/the C compiler.</div><div><br></div><div>2. It enables debugging information for compiled code, within the Gambit environment, so that |pp|, |bt| etc. will show code instead of nothing/just #<procedure 123>.</div><div><br></div><div>3. It enables debugging information for compiled code, on the level of the C code, so that GDB/the C-level debugger, will show Scheme code too (right?)</div><div><br></div><div>4. It enables the production of theĀ </div><div><br></div><div>5. Some more stuff maybe?</div><div><br></div><div><br></div><div>The disaster happens in 4. : your "console" file will fill the disk which causes system havoc, and "rm console" will not fix the problem as the OS will unlink the file at first when you close Gambit, duh!</div><div><br></div><div>However, to the best of my awareness, there is no way to enable/disable the debugging options with any granularity at all. The only convenient option below the disastrous "--enable-debug", is "CC_FLAGS="-g" ./configure", which enables too few options and hence is unsatisfactory.</div><div><br></div><div><br></div><div>This overall gives me the impression that the debugging options have not been tailored to match the needs for users (i.e. for helping users debug their code) but for Gambit development (for helping resolve internal Gambit bugs and aid Gambit system development).</div><div><br></div><div><br></div><div>What I would like here is simply to be able to enable/disable these five individually.</div><div><br></div><div>In normal cases, I want 1-3 to be enabled, and all else disabled.</div><div><br></div><div>I consider 4-5 to be for debugging of the Gambit system itself, only.</div><div><br></div><div><br></div><div>Probably normally, I'd actually make 1 going via CC_FLAGS as I want to choose the C compiler's -O option myself, and then use the specific ./configure arguments for enabling 2 and 3 only - and hence implicitly keep the feared 4 (and any 5 that I wouldn't want anyhow), disabled.</div><div><br></div><div><br></div><div>Would you be able to implement this this year?</div><div><br></div><div>Any comments from other users would also be much appreciated.</div><div><br></div><div>Thanks!</div></div>