A performance-oriented Lisp-like language where I can have my cake, and eat it (too)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

1.5 KiB

#+TITLE:Debugging Cakelisp Cakelisp doesn't really have an interpreter. Cakelisp always generates C/C++ code to do meaningful work. This means the Cakelisp transpiler, macros, generators, and of course final code output can be debugged using a regular C/C++ debugger like GDB, LLDB, Or Visual Studio Debugger.


Run cakelisp --help to see what command-line arguments may be passed in to control verbosity. If Cakelisp is doing something you don't expect, it may help to turn on verbosity for the sub-system you expect may be at fault.


The following command may be run in order to tell GDB where the .so files you want to debug are located:

set solib-search-path ~/Development/code/repositories/cakelisp/cakelisp_cache
set cwd ~/Development/code/repositories/cakelisp/

(adjust that path to where you installed cakelisp, of course).

By setting a breakpoint in already generated C++ code, you will then hit the breakpoint once the code is regenerated and loaded at transpiler runtime (a.k.a. compile-time code execution).

Microsoft Visual Studio Debugger

Pass --wait-for-debugger to Cakelisp. This argument gives you time to Debug -> Attach to Process. This is useful if you don't want to have to make a Visual Studio project just to debug Cakelisp.

If you want to debug a compile-time function, run Cakelisp once to generate the file, then open it in Visual Studio and set a breakpoint. You should hit the breakpoint even though it's in a dynamically-loaded library.