<div dir="ltr">Great question. To look into what debug levels could be made of, for clarity let's first look into what debug functionality is implemented i.e. is enabled on --enable-debug , so now question back to you:<div>

<div><br></div><div>Is the following list complete, or is there anything to add to or to correct about it?</div><div><br></div><div><br></div><div>--enable-debug brings:</div><div> 1) Debug symbols at the level of C by passing -g to C compiler, making it include C-level debug symbols</div>

<div> 2) Debug symbols at the level of Scheme, by Gambit including in the GVM/C code all define names and their code locations for display in code traces like ,be</div>
<div> 3) Generation of the "console" file</div><div> 4) GC heap consistency checks ability, only invoked if enabled on runtime (ENABLE_CONSISTENCY_CHECKS)</div><div> 5) GC: Generation of the movable_pair_objs and movable_subtyped_objs variables introspectable via GDB (GATHER_STATS)</div>

<div><br></div><div>--enable-debug does *not* bring:</div>
<div> 6) Individual tracing of malloc&free:s beyond ___base_mod.alloc_mem_calls != ___base_mod.free_mem_calls check on exit (___DEBUG_ALLOC_MEM_TRACE)</div><div> 7) GC debug output (___DEBUG_GARBAGE_COLLECT)<br></div>

<div> 8) TTY state dumps (___DEBUG_TTY)</div>
<div> 9) ___DEBUG_STACK_LIMIT and ___DEBUG_HEAP_LIMIT (not sure how it works out)<br><div class="gmail_extra"> 10) ___DEBUG_HOST_CHANGES (no clue what this is, seems insignificant anyhow)</div><div class="gmail_extra">( * And then to make this discussion complete, regarding all the ___DEBUG_SETTINGS_* defines: These are not influenced at all by --enable-debug but are compiled in always and describe settings only enabled on runtime given command line arguments as parsed in main.c , and they're all unused in the code except for for enabling the GC consistency checks.)</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Regards,</div><div class="gmail_extra">
Mikael</div><div class="gmail_extra"><br><div class="gmail_quote">2013/9/17 Marc Feeley <span dir="ltr"><<a href="mailto:feeley@iro.umontreal.ca" target="_blank">feeley@iro.umontreal.ca</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div><div><br>
On 2013-09-07, at 10:12 AM, Mikael <<a href="mailto:mikael.rcv@gmail.com" target="_blank">mikael.rcv@gmail.com</a>> wrote:<br>
<br>
> Dear Marc,<br>
><br>
> What is the best practice for configuring Gambit to maintain maximum debug settings switched on but no output of a "console" file?<br>
><br>
><br>
> (<br>
> By maximum debug settings, I mean export of debug symbols, so this could be done by CFLAGS="-g" CXXFLAGS="-g" ./configure , and optionally "-o0" or "-o1" on that -<br>
><br>
> And.. is there any more debug level functionality in Gambit, for instance does --enable-debug switch on any debug functionality beyond -g and "console" file output?<br>
><br>
> The console file is not needed as it's of such a lowlevel nature, and it easily grows infinitely as in >>100GB.<br>
><br>
> Also, switching off while maintaining --enable-debug requires such large amounts of code changes, that I'd presume --enable-debug actually was intended first and foremost as an enabler of "console" file output?<br>



> )<br>
><br>
> Thanks!<br>
> Mikael<br>
><br>
<br>
</div></div>I'll turn your question back into a question to you... what would be appropriate levels of debugging?  What do you need specifically?  I can add configure flags and runtime options to control the debugging level.<br>



<span><font color="#888888"><br>
Marc<br>
<br>
</font></span></blockquote></div><br></div></div></div></div>