nim c --debugger:on -r ./binName
This will take you to command line debugger, where you can add breakpoints and inspect vars.
When I run "nim c --debugger:on --parallelBuild:1 test.nim" on macosx 10.10.4
Hint: test [Processing]
clang -c -w -I/Users/xxx/SDK/nims/Nim/lib -o /Users/xxx/SDK/nims/mytest/nimcache/test.o /Users/xxx/SDK/nims/mytest/nimcache/test.c
clang -c -w -I/Users/xxx/SDK/nims/Nim/lib -o /Users/xxx/SDK/nims/mytest/nimcache/stdlib_system.o /Users/xxx/SDK/nims/mytest/nimcache/stdlib_system.c
/Users/xxx/SDK/nims/mytest/nimcache/stdlib_system.c:1433:2: error: use of
undeclared identifier 'F'
F.s[0].address = (void*)&result; F.s[0].typ = (&NTI108); F.s[0]....
^
/Users/xxx/SDK/nims/mytest/nimcache/stdlib_system.c:1433:35: error: use of
undeclared identifier 'F'
F.s[0].address = (void*)&result; F.s[0].typ = (&NTI108); F.s[0]....
^
...
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
Error: execution of an external program failed
It might be buggy for 0.11:
WARNING: ENDB is not maintained anymore! Please help if you're interested in this tool.
You may need to go with the GDB solution.
Well, GDB/LLDB can use, Thank you everybody.
Hope endb can use in later version.
xyz32: Do you know if there is a way to tell nimble to guild a debug build?
This is currently hard-coded into nimble. nimble install will make a release build, nimble build won't. You can work around that by putting the desired command line options in a config file, but my recommendation is to simply use a proper build tool (such as make or scons) for applications instead of working around the limitations of nimble (which is primarily a package manager, not a real build tool).
@Jehan I am not a big fun of build tools that only tell you what you are missing (if you are lucky) and don't even try to help you in any way. Make was a necessity for C/C++ as the compiler needs to be feed all the necessary files to be able to work. Nim can figure most of that on its own :).
@Angluca If you use KDE and you like KDevelop, it has a nim/nimble project template, build, install and (with bit of a hack-ish way of switching between release an debug) break points support. Auto-complete is not yet working, I think it may require a bit of c++/qt for that. You can see an example here:
I followed this
http://hookrace.net/blog/what-makes-nim-practical/#debugging-nim
but gdb does not stop on a breakpoint:
$ nim --d:debug --lineDir:on --debuginfo --debugger:native c hello.nim
$ gdb hello
(gdb) b hello.nim:3
Breakpoint 1 at 0x145c: file /tmp/hello.nim, line 3.
(gdb) r
Starting program: /tmp/hello
Hello World
Value of x: 10
During startup program exited normally.
Do you know what could be wrong?
nim: Nim Compiler Version 0.17.1 (2017-07-18) [Linux: amd64], gdb: 7.12.50
well I always put my breakpoints on functions. So like this
(gdb) b foobar<TAB>
(gdb) b foobar_123456789987654321<enter>
it is a bit more robust on the terminal than lines. And don't underestimate (gdb) tui enable. I wasted a lot of time with GDB. I think it's a horrible interface, but technically it works.
your example works and my example also works.
Last week I switched to Xonsh and this was the problem, it works when I run
env SHELL=/bin/bash gdb hello