Hi, I trying to ease my pain debugging Nim. Thinking if anyone already implemented GDB pretty printers for Nim basic types.

Visual studios natvis debug custrom visualizers will also work.

Thank you

2017-07-28 16:11:51

Haven't seen any, good idea. Should be pretty easy for seqs, arrays, strings and pretty useful when debugging.

I'd also be interested if it's possible to demangle identifiers so that we can tell GDB what the mapping between original identifier and C identifier is, like the #line pragma.

2017-07-28 16:38:27

I noticed nim compiler has --genMapping option that generates ndi files with useful mapping.

Unfortunately, compilation itself fails when --genMapping is enabled.

2017-07-31 09:25:10
There seems to be a bug, but I'm not sure about the intended usage: https://github.com/nim-lang/Nim/issues/1592
2017-07-31 09:58:17

well, I once did an approach to this, feel free to use it.

This macro embeds the gdb python script into the executable, when it is build on Linux. Alternatively you can also load the script from gdb, but once this works there is no hassle involved anymore. https://github.com/krux02/opengl-sandbox/blob/master/fancyglpkg/debug.nim

Here is the gdb script, but I haven't used it for a time. https://github.com/krux02/opengl-sandbox/blob/master/fancyglpkg/nim-gdb.py

2017-07-31 11:20:46

Thanks Krux02,

I have tried it, it works as intended for strings and I couldn't make it to work for anything else. Names of the types is not sufficient indicator to determine whether it is enum, union, set and etc. What is probably I am after is compiler generates some useful file that python script can consume.

It is hard to believe no one has done it so far, I quickly reached the point where putting renderTree,typeToString and debug everywhere in Nim compiler no longer helps understanding what is going on. I don't see how one can contribute without solving the debugging dilemma.

2017-08-01 18:33:44

I totally agree with you, debugging is really a weak spot in Nim.

Things I just don't understand:

By default Nim does build in debug mode, but it does not provide debugging symbols (-g flag for the C compiler), so that you can't actually debug with gdb your debug build. When I complain that this is an issue, I get told, that it is in fact not an issue and I should just change my nim.cfg. Alternatively I can simply add the --debugger:native flag to the compiler.

The gdb integration I just showed, is something that could be done from the Nim compiler, so that all Nim applications, that are build in debug mode have already the gdb scripts self contained in the binary, so that they can be loaded from gdb automatically and work magically in any frontend for gdb. Meaning there would be nothing in the way for debug builds to work with zero configuration in every editor.

But yea, it's just me who thinks this way, and passing --debugger:native as an additional flag to a debug build in case someone wants to actually debug the debug build is a good default.

2017-08-03 04:43:43

Hi Krux02,

I have seen your pull request has been merged. Great job. I immediately started testing. I see that string, seq and array pretty printing is now working great. Objects and Tuples were fine anyway.

I believe we still have some problems with: Enums, Discriminated Unions and Sets. Let's solve this problem once and for all. It is the most rewarding contribution for Nim community I can think of.

I suggest starting further discussions what changes are required to display Enums and Discriminated Unions properly.

P.S. It could be possible to introduce new $ command into gdb that will extract a type of the argument and will check if suitable dollar operator implementation exists in global symbol table. I have started looking into that.

2017-08-10 16:31:06

For enums there is a useful function reprEnum that is always compiled into final executable. It accepts two arguments: enum value (good) and TNimType*.

Does anyone know how to get second argument in a generic way outside of Nim?

Many thanks

2017-08-10 16:47:37