[gambit-list] Best way to build gambit on Windows with debug information

Marc Feeley feeley at iro.umontreal.ca
Tue Jan 1 10:42:04 EST 2019


The performance of the system is affected by the level of debugging support selected by the configure options.  Some of the debugging options are very fine grained and log information to a file (gambit.log).  This performance slowdown is moreover amplified by the use of SMP because all processors will be logging to the same file (and this also makes the information hard to read).

The option --enable-debug-host-changes is *extremely* expensive because it logs every transfer of control between functions that go through the trampoline.  It exists for debugging hard to debug situations where it is important to know what were the last few function calls that led to a bug.  So this is kind of a “last hope” when other debugging techniques have failed to solve a bug.  The (newer) option --enable-debug-ctrl-flow-history was created to give approximately the same information when the program crashes, but it logs the information in memory and only dumps it to gambit.log when the program crashes, so it is much more efficient.

The option --enable-debug-garbage-collect will slow down the GC depending on the debugging level runtime option.  When a debugging level >= 1 is used, for example -:d2, the GC will perform checks that detect when the heap is in an inconsistent state (due to a bug in the GC or the rest of the system).

The other debugging options are much less expensive.

As an example, on my machine after a “make bootstrap”, a “make bootclean;make” takes about 4 minutes when only the --enable-single-host option is used and about 16 minutes when all debugging options except --enable-debug-host-changes are used.  With --enable-debug-host-changes it would probably take a few days or maybe weeks…

Marc



> On Jan 1, 2019, at 6:12 AM, luca regini <luca.regini at gmail.com> wrote:
> 
> Hi All,
> I am trying unsuccessfully to build Gambit on Windows with debug information.
> 
> I am using MSYS2 with mingw-64 as the build environment.
> The version of gcc that comes with this distribution is:
> gcc version 7.3.0 (GCC)
> and the thread model is posix
> 
> I have configured the build with the following options:
> ./configure --enable-single-host --enable-debug --enable-debug-log
> --enable-debug-c-backtrace --enable-debug-ctrl-flow-history
> --enable-debug-host-changes --enable-debug-alloc-mem
> --enable-debug-garbage-collect --enable-rtlib-debug-location
> --enable-rtlib-debug-source --enable-rtlib-debug-environments
> --enable-track-scheme --enable-thread-system=win32
> --enable-multiple-threaded-vms --enable-smp
> 
> and have done a full boostrap.
> the make bootstrap and make bootclean steps work fine but the make
> takes forever.
> 
> It has been running for more than 1 hour and 25 minutes now on the
> first file ( _io.scm ) and there is no visible sign of progression.
> 
> I have intentionally run it only with one thread since running
> multiple build threads ( make -jn) was always saturating my cpu to
> 100%.
> I am building on a laptop running Windows 10 with 2 cores and 16 GB of RAM.
> 
> What are some clearly reproducible steps to build on Windows with
> debug info? There are several possible choices even about what MSYS (
> Mingw32/64, MSYS1, MSYS2, Visual Studio can build without a bootstrap
> or not?)  distribution one can use and this are not very well
> documented on the website.
> _______________________________________________
> Gambit-list mailing list
> Gambit-list at iro.umontreal.ca
> https://mailman.iro.umontreal.ca/cgi-bin/mailman/listinfo/gambit-list



More information about the Gambit-list mailing list