Mirror of forum.nim-lang.org

11377 :: situation with GDB debugging?

• mszs (orginal) [2024-04-06T19:46:35+02:00] view original

  I'm having problems with debugging. Not sure whether it's just me...

  When I compile for debugging and I load the resulting executable into nim-gdb, the symbol table seems off. I've tried this with 2.0.2 as well as 1.6.18. The location for the main function/program entry point is not the same in both cases, but it's wrong in both cases. For example,

  proc main() =
    echo("sed -i -e '/^[^,]*,#N\\/A,.*$/d' ")
  
  main()
  Run

  compiled with 1.6.18 and loaded into nim-gdb results in

  
  (gdb) start
  Temporary breakpoint 1 at 0xc0b0: file /home/marko/.choosenim/toolchains/nim-1.6.18/lib/system.nim, line 2239.
  Starting program: /home/marko/tmp/test
  
  This GDB supports auto-downloading debuginfo from the following URLs:
    <https://debuginfod.archlinux.org>
  Enable debuginfod for this session? (y or [n]) y
  Debuginfod has been enabled.
  To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
  Downloading separate debug info for /lib64/ld-linux-x86-64.so.2
  Downloading separate debug info for system-supplied DSO at 0x7ffff7fc6000
  Downloading separate debug info for /usr/lib/libc.so.6
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/usr/lib/libthread_db.so.1".
  
  Temporary breakpoint 1, main (argc=1, args=0x7fffffffd428, env=0x7fffffffd438) at /home/marko/.choosenim/toolchains/nim-1.6.18/lib/system.nim:2239
  2239	   nimCmpMem(a, b, size) == 0
  (gdb) list
  2234	 proc moveMem(dest, source: pointer, size: Natural) =
  2235	   c_memmove(dest, source, csize_t(size))
  2236	   when declared(memTrackerOp):
  2237	     memTrackerOp("moveMem", dest, size)
  2238	 proc equalMem(a, b: pointer, size: Natural): bool =
  2239	   nimCmpMem(a, b, size) == 0
  2240	 proc cmpMem(a, b: pointer, size: Natural): int =
  2241	   nimCmpMem(a, b, size)
  2242
  2243	when not defined(js):
  Run

  with 2.0.2 it's a different source line, but also incorrect. Could this be a local - configuration - problem? Or are others seeing similar problems? Is this a well-known issue? Is someone already working on it?

---

• mszs (orginal) [2024-04-06T20:06:30+02:00] view original

  It hadn't occurred to me before to try setting the breakpoint explicitly to a line (e.g. line 2) and then to run the program in the debugger: well, that does what one expects. So, possibly it's only the start command that's not operating as expected. I'd be happy if it's just that: I can live with that.

---

• janAkali (orginal) [2024-04-07T06:13:23+02:00] view original

  First, see semi-official guide on Nim debugging.

  Also this is an excellent guide: https://internet-of-tomohiro.netlify.app/nim/gdb.en.html

  start doesn't work as you'd expect because in Nim there are multiple mains: one is C's and other one defined in your source code. Gdb's start tries to find C's main in Nim code and it's probably not very useful for you.

  To get to the useful main (one in your source file), you can just set a breakpoint b test::main and run until it reaches it. Then everything including list should work as normal.

---

• mszs (orginal) [2024-04-09T17:39:46+02:00] view original

  The thing is that I had read and used all the resources on Nim debugging that I could find including the ones you link to. But it seems I was so much a creature of habit that it did not occur to me that start could be the source of the problem... That's why I posted the follow up, so that someone coming here with the same issue, will find it.

---