Hacker News Reader

Comment by Joker_vD | Hacker News Reader

> And finally, source-level debugging is gnarly. You would like to be able to embed DWARF information corresponding to the code you residualize; I don’t know how to do that when generating C.

I think emitting something like

    #line 12 "source.wasm"

for each line of your source before the generated code for that line does something that GDB recognizes well enough.

View on HN

If you have ever used something like yacc/bison, debugging it is relatively sane with gdb.

You can find all the possible tricks in making it debuggable by reading the y.tab.c

Including all the corner cases for odd compilers.

Re2c is a bit more modern if you don't need all the history of yacc.

Debugging Yacc is completely insane with gdb, for other reasons, like that grammar rules aren't functions you can just put a breakpoint on, and see their backtrace, etc, as you can with a recursive descent parser.

But yes, you can put a line-oriented breakpoint on your action code and step through it.

I dabbled into literate programming and wrote C basically in reStructuredText. Used '#line' to specify the correct file name and line number in my reStructuredText sources. Worked as advertised, no complaints.

In my case I had long-ish fragments, so I only put '#line' at the start of a fragment. The compiler counted subsequent lines itself.

It was a cross-platform project and worked equally well with GCC, Clang and MS Visual C++.

Nim compiles to C, and it has a compiler iotion that does this.

The CPP does that as well, because once the compiler is invoked, the original source code file is already gone.

Reply on news.ycombinator.com