How do you debug ANY compiled language? Every compiler compiles to another language. ;)

https://en.wikipedia.org/wiki/Compiler "A compiler is a computer program (or a set of programs) that transforms source code written in a programming language (the source language) into another computer language (the target language), with the latter often having a binary form known as object code."

GCC supports some special pragmas that Nim puts in the generated code. It then transparently maps the Nim source to the compiled instructions. This is exactly like JS sourcemaps for languages that compile to JavaScript. I haven't tried it that much, but it seems to work pretty well.

To be honest, I never managed to get familiar with many debuggers in a fashion that I could use them productively, except for Microsoft's Visual Studio tools (VC++, good ol' VB6 :-)). I know enough GDB to survive, and from what I've seen Nim works there almost just as well as plain C code.

There was a special debugger for Nim that worked by inserting instrumentation code during compilation, but that seems to have been deprecated.

Alright, thanks everyone! Mystery solved! :)

GDB and Valgrind work quite well, see for example:

- https://hookrace.net/blog/what-makes-nim-practical/#debuggin...

- https://hookrace.net/blog/writing-an-async-logger-in-nim/#op...

Edit: You can of course also change the program itself, using echo and writeStackTrace to figure out what's going on.

Aside from using GCC's debugging information, you can emit code that creates its own debugging information in some run-time structure.

For example, at the beginning of each function call, you insert a function call that pushes a new stack frame into some global stack, and store the function's arguments. Then, just before every return from the function, you pop the stack frame. When the program crashes, you write the stack to a JSON file, and use a language-specific debugger to view it.

Pretty much the same way you can any other language. GDB/LLDB works fairly well with Nim, but personally I just use a couple `echo` statements when I need to debug anything.

Yup, the source code still appears in GDB and with a bit of tab completion, inspecting variables ain't that hard, either. I've had worse experiences with C code that abused the preprocessor.

`printf` debugging is still often the easiest way to go.

GDB looks intimidating, but once I decided to try it I'd never go back to printf debugging.

Oh yes, I've used it for many years (though many years ago). For me it depends on the size of the program and the compile time; if it's a short one and compiles quickly, I'll throw a print/puts/print/echo in there just to see what's going on.

That's what happens with "real" debuggers, in my experience! Though Codebug (for XDebug in PHP) is what did it for me, but now I'm using interactive debugging wherever I can. Beats the hell out of trying to print out variables.

So many circular answers. Maybe someone could give some pointers to @Keyframe1 about best practices in nim, I'm sure he knew gdb worked with nim.

I agree. I don't get it. It seems no one has actually tried it. What I'm asking is what's the idiomatic approach to debugging this. If I code in Nim and produce C code and then compile and link that... I'm debugging produced C code, which is below Nim in the chain. I have to somehow then see what's up with exact Nim code that produced said C code which got compiled and linked. It's two steps remove with a magic, unexplained, step between Nim and C which I'm asking about how to debug.

Javascript targetting languages have source maps to link back errors at the lower level back to the pre-compiled source. Clojure dealt with the dual nature of errors (clojure exception from java exception) by partitioning messages in sub-groups to facilitates reading.

That's the answer I was looking for. I was unaware of that. I presume Nim provides something like that as well?

Nim can add #line directives into the generated C source code which map back to the Nim code. GDB can use this information.

I don't know, I only compiled nim once last year to see what kind of C code would show up. I ran away because there was a lot of expansion.

That happens a lot on HN and it is frustrating. It's clear that people have just the barest of experiences with a topic and then speak with authority, to the detriment of others. I try not to comment on things I don't know about and if I do, then I make it clear that I am extrapolating and don't try to come off like an expert because I can google a topic.

I submit to useless comments too, but not when there's already 7 times the same snub one in a row already.

You mean like how C compiles to assembly?

That's not a good analogy, because C doesn't just compile to assembly in any modern compiler. It compiles to assembly plus DWARF, which is an extremely expressive metalanguage (far beyond #line) for describing the mapping from the generated code back to the source. C has no mechanism for inserting raw DWARF DIEs, while assembly does.

for gdb it looks like you (as a developer of a language that compiles to c) can use #line directives as a means of source-mapping. [1]

[1] http://ftp.gnu.org/old-gnu/Manuals/gdb/html_chapter/gdb_11.h...

Nim adds those directives for you with the ``--linedir:on`` switch.

Which is automatically set if you compile with --debugger:native

You map the output back to the input.