2

In the scenario of debugging a remote target running a custom RTOS, what would be necessary to add thread support to GDB?

In my case I have access to the RTOS sources and debug info for all its scheduler's symbols, so theoretically the information is accessible.

Would this imply recompiling GDB? Adding hooks to thread-related commands?

Any commentary will be greatly appreciated!

salicideblock
  • 388
  • 3
  • 8
  • When you type `info threads` in GDB, what information do you get back? What requests does it make to your target? You should be able to use that information to get it working. – Carl Norum Sep 19 '11 at 20:45
  • Oh sorry, I should have mentioned I had already tried that. GDB answers with a "this target does not support threads" error. – salicideblock Sep 19 '11 at 20:49

1 Answers1

2

You need to add thread support (and in particular, support for H and qXfer:threads:read packets) for your gdb RTOS stub. Documentation here and here.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • Thank you. I hadn't thought to look into the packets documentation. Your links will be a great start. – salicideblock Sep 20 '11 at 23:38
  • As stated in http://events.linuxfoundation.org/sites/events/files/slides/ELC-E%20Linux%20Awareness.pdf the JTAG solution for RTOS awareness is preferable to modifications in the RTOS itself. But I do not think that GDB C extensions are the way to go, because there could not be a dependency for every RTOS in GDB. Therefore I would prefer the python extension way. But it seems, that the thread handling is not exposed to python yet. Does anyone have more information? Is it planned? – Zappel Sep 03 '16 at 12:16
  • Found newer slides and something from the mailing list: http://events.linuxfoundation.org/sites/events/files/slides/Debugging%20the%20Linux%20Kernel%20with%20GDB.pdf https://sourceware.org/ml/gdb-patches/2015-06/msg00040.html – Zappel Sep 03 '16 at 12:29