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.

Answer 3

Wind River certainly encourages the use of Workbench for inspection style debugging (which makes sense because it requires a Wind River license), but it does seem there are ways to use GDB with some configuring to debug tasks in VxWorks. See this old GDB VxWorks manual. Now this manual is from 2002, so I would imagine quite a few things are not up to date, but hopefully this helps you out (if of course modern versions of VxWorks provide legacy support for the methods detailed in this document).

And as you most likely know, VxWorks supports basic print-based styles of debugging which can be preformed by printf() or the superior logMsg() function from logLib.