problems integrating Nim pretty printers

[krux02]

Describe the bug
I have written gdp pretty printers in python for the programming language Nim. When I run gdb from the console, everything runs fine. But when I run gdbgui instead of gdb, my gdbinit is executed. I can see that my pretty printers work. But after the output that was caused by my gdbinit, there are also some error messages.

this is my .gdbinit

source nim-gdb.py
break bar
run

in the screenshot you see the output. As you can see, my breakpoint has been reached successfully, but the the line set breakpoint pending on that I marked, does not come from me. And all the error messages later are also not coming from me. Also the stack trace on the right is not from me.

To Reproduce

git clone [email protected]:krux02/Nim.git
cd Nim
# checkout my feature branch
git checkout macro-in-generic-type
# clone and compile the bootstrapping compiler
git clone --depth 1 https://github.com/nim-lang/csources.git
cd csources
sh build.sh
cd ..
# compile the build tool for the compiler
bin/nim c koch
# compile the real version of the compiler
./koch boot -d:release
# compiler the tiny project that I use to develop the pretty printers
bin/nim c --debugger:native scratch.nim
# start gdbgui on that project
gdbgui scratch

Screenshots

Please complete the following information:

• OS: Debian 7.12-6
• gdbgui version: 0.12.0.0:
• gdb version: (7.12.0.20161007-git)
• browser: chrome
• python packages: None

Additional context

[cs01]

Hi thanks for reporting this.

gdbgui sends commands "behind the scenes" to try to make the experience as good as possible. Sometimes they need some fine tuning. This might be the case here since it looks like you're using nim, which I did not know could be used with gdb (or even existed 😄 ).

Regarding set breakpoint pending on that command is sent by gdbgui automatically. There is no option to send/not send it though. I should probably add one to turn it on/off.

I suggest going to settings (gear icon in top right) and unchecking Add breakpoint to main after loading executable.

I suspect this breakpoint is added to the address of the main function in a way that gdb could not determine the associated source file, so it puts you in some weird low-level stack at that address and maybe is the source of the "unable to read memory" errors.

See if that helps. If not, go back to settings and check Print all sent commands in console, including those sent automatically by gdbgui. Then reproduce all of the spam you get in the console. That will let us see what commands gdbgui is sending and hopefully determine the root cause of the messages.

[krux02]

Thank you for the support. I will try your suggestion as soon as I am back to work. A bit of information about Nim. It is a language that compiles to C with source mapping so that gdb actually sees the Nim files and not the C files. But the underlying data structures are all generated C data structures. That is why pretty printers are so important.

[krux02]

So I did try it out now here at home. So setting the breakpoint for main does not do the effect. But thank you for pointing out that I can disable it. The breakpoint in main isn't very usable becaues that is where the nim runtime is setup. And normally you don't want to debug that. I did find a workaround though.

When I do not have a local .gdbinit, then everything works. But then I also don't have my python script loaded, so I have to type manually 'source nim-gdb.py' inside of gdbgui. I can also hit restart in gdbgui, but then for some reason my python module is unloaded and I have to do 'source nim-gdb.py' as well.

Another issue I have right now. I don't see the string representation of 'NCSTRING'. It just pretends it's a pointer to a single character. But I wrote a pretty printer with the correct output. you can see it in the gdb window.

And the last thing, on the call stack, the arguments to the functions are not listed. This is also gdbgui only, because bt on the terminal works nicely.

[krux02]

There is also an issue I have for types where I have the pretty printer overloaded. All of a sudden I can't expand those types anymore. Before I could inspect all the members, now I just can't they are gone. In the screenshot you see on the console that print conf.configVars works nicely. And it works with the pretty printer children iterator. But the configVars field in the tree view (sorry that it is so hard to find) is not expandable. It just has this non-informative {...} annotation.

[krux02]

You asked me to send you an e-mail. I just wanted to post that content here as well.

Here is the transcript. I inserted some whitespace in the output of
gdb to make it easier to parse for humans. The real output had no
whitespace beween the elements.

(gdb) -var-create searchPaths * conf.searchPaths

    name="searchPaths",
    numchild="0",
    value="{...}",
    type="tySequence_sM4lkSb7zS6F7OVMvW9cffQ *",
    thread-id="1",
    displayhint="array",
    dynamic="1",
    has_more="1"

(gdb) -var-list-children searchPaths

    numchild="15",
    displayhint="array",
    children=[
      child={name="searchPaths.data[0]",exp="data[0]",numchild="0",type="NimStringDesc *",thread-id="1",displayhint="string",dynamic="1"},
      child={name="searchPaths.data[1]",exp="data[1]",numchild="0",type="NimStringDesc *",thread-id="1",displayhint="string",dynamic="1"},
      child={name="searchPaths.data[2]",exp="data[2]",numchild="0",type="NimStringDesc *",thread-id="1",displayhint="string",dynamic="1"},
      child={name="searchPaths.data[3]",exp="data[3]",numchild="0",type="NimStringDesc *",thread-id="1",displayhint="string",dynamic="1"},
      child={name="searchPaths.data[4]",exp="data[4]",numchild="0",type="NimStringDesc *",thread-id="1",displayhint="string",dynamic="1"},
      child={name="searchPaths.data[5]",exp="data[5]",numchild="0",type="NimStringDesc *",thread-id="1",displayhint="string",dynamic="1"},
      child={name="searchPaths.data[6]",exp="data[6]",numchild="0",type="NimStringDesc *",thread-id="1",displayhint="string",dynamic="1"},
      child={name="searchPaths.data[7]",exp="data[7]",numchild="0",type="NimStringDesc *",thread-id="1",displayhint="string",dynamic="1"},
      child={name="searchPaths.data[8]",exp="data[8]",numchild="0",type="NimStringDesc *",thread-id="1",displayhint="string",dynamic="1"},
      child={name="searchPaths.data[9]",exp="data[9]",numchild="0",type="NimStringDesc *",thread-id="1",displayhint="string",dynamic="1"},
      child={name="searchPaths.data[10]",exp="data[10]",numchild="0",type="NimStringDesc *",thread-id="1",displayhint="string",dynamic="1"},
      child={name="searchPaths.data[11]",exp="data[11]",numchild="0",type="NimStringDesc *",thread-id="1",displayhint="string",dynamic="1"},
      child={name="searchPaths.data[12]",exp="data[12]",numchild="0",type="NimStringDesc *",thread-id="1",displayhint="string",dynamic="1"},
      child={name="searchPaths.data[13]",exp="data[13]",numchild="0",type="NimStringDesc *",thread-id="1",displayhint="string",dynamic="1"},
      child={name="searchPaths.data[14]",exp="data[14]",numchild="0",type="NimStringDesc *",thread-id="1",displayhint="string",dynamic="1"}
    ],
    has_more="0"

(gdb) -var-evaluate-expression searchPaths

    value="{...}"

(gdb) -var-show-attributes searchPaths

    attr="editable"

(gdb) -var-evaluate-expression searchPaths.data[3]

    value="\"/home/arne/proj/nim/Nim/lib/pure/unidecode\""

(gdb)-var-show-attributes searchPaths.data[3]

    attr="editable"

(gdb) -var-info-num-children searchPaths

    numchild="15"

This is how the exact same variables looks like in gdbgui.

[krux02]

cool, thank you for working on this.

[cs01]

Sure, let me know if you get a chance to test it out.

[krux02]

Sure I will. But it could take a while, because I don't have any active Nim projects right now.