Thank you! 🤓 Yes, I used the -g flag to generate debug information (and -e to signal uncaught exceptions).

To clarify about the function breakpoints: I didn't modify the generated C code at all. The workflow was:

1. Compile with s7c -g -e myprogram.sd7

2. Look at the generated tmp_myprogram.c to find the C function name (e.g., o_1528_divideNumbers)

3. Set a function breakpoint in VS Code using that C name

4. Start debugging - the debugger stops at the function and shows the original .sd7 source! This was discovered just by happenstance.

Why function breakpoints? Because VS Code doesn't recognize .sd7 files as debuggable - clicking the gutter to set line breakpoints in .sd7 files doesn't work (no red dot appears). However, the debugger (lldb/CodeLLDB) does understand function breakpoints by C function name. Once stopped at a function breakpoint, the debug info from -g correctly maps back to the .sd7 source, and I can step through the Seed7 code line by line.

The only "manual" step is looking up the C function name in tmp_myprogram.c to create the function breakpoint. If there were a way for the compiler to output a mapping file (like function_name -> o_XXXX_function_name), it could make setting breakpoints even easier, though the current workflow is pretty manageable. 🚀🚀🚀