VxWorks debugging without workbench

Question

Is it possible to debug a VxWorks task without the Workbench with GDB or another free debugger? Looking online it is only reported an old command for gdb (target vxworks ID) that does not work anymore; moreover after VxWorks 5.3 has been introduced the WDB protocol that looks like has never been ported into gdb except for one tentative on a vetust version and only for PowerPc platforms (I need to debug an x86 VxWorks 6.9)

Answer 1

Try -> dbgHelp on VxWorks target shell, which displays interactive shell debug commands.

Answer 2

I have no idea what versions that it was, but many years ago I created gdb2wdb for this exact purpose for FRC robots that use VxWorks. The code hasn't been maintained since FRC moved to a Linux-based system, but I see no reason why that shouldn't work with some tweaking of constants & gopher strings to be less FRC-specific.

GDB2WDB is a Ruby script similar to a gdbserver process, in that you run gdb2wdb on your local machine and point it to your vxworks box, and then point gdb to gdb2wdb via target remote :2345.

If memory serves correctly, it can be run with any version of ruby after 2.0.1 (or jruby after 1.7) as such:

ruby -I lib bin/gdb2wdb [your-arguments-here]

Check out the --help argument and note this FRC-specific terminology and layout:

• cRIO - the name of the controller that had VxWorks on it. PowerPC based
• FRC_UserProgram.out - the kernel module that FRC robot code was uploaded in
• FRC_UserProgram_StartupLibraryInit - Entry point for FRC robot code
• FRC_RobotTask - main thread of FRC robot code
• powerpc-wrs-vxworks - the stock GCC triplet used for FRC robot code

Also make sure the linker settings (in lib/elf_utils.rb) are applicable, and the GOPHER commands in WdbGopherStrings (from lib/wdb/wdb.rb) probably require tweaking of offsets/addresses for various versions of vxWorks & x86. They can be synthesized from the C headers (p. 160-167) or from a Wireshark capture of an existing Workbench debugger session.

Important note: gdb2wdb is quite the hack, and many features are unsupported, but I do remember at the time that I implemented enough to be able to use stock Eclipse CDT + gdb, so it should be enough for simple cases.