using libdebugger

[Chris Johns]

On 29/4/20 6:37 pm, Mario Palomares wrote:
> Hi everybody,
> 
> I'have seen in the documentation, Users Manual/Debugging, that there is 
> a possibility to do remote debugging with the libdebugger library. But 
> there, it only mentions the possibility, it doesn´t explain how to set 
> it up.
> I'have searched for some documentation about it and found this:
> 
> https://docs.rtems.org/releases/rtemsdocs-4.7.1/share/rtems/html/rgdb_specs/rgdb_specs00011.html
> https://docs.rtems.org/releases/4.5.1-pre3/rtemsdoc/pdf/rtems_gdb.pdf
> 
> I have also checked the header files in the source tree, but still need 
> some guidance.
> 
> Could explain a little about this or reference me some useful documentation?
> 

Only a limited number of architectures are supported and some like the 
ARM thumb mode are experimental. I do apologise for the lack of 
documentation, most of the recent work is unfunded, i.e. ARM support, 
and any time I have is spent on the code.

The set up is simple as the test code in libbsd shows:

https://git.rtems.org/rtems-libbsd/tree/testsuite/debugger01/test_main.c

Note:

a) Add `-ldebugger` to your list of libraries when linking your application.

b) Make sure you have the network running for the TCP transport before 
starting the debugger.

Setup
-----

1. Optionally add the debugger shell command using:

  rtems_shell_add_cmd_struct(&rtems_shell_DEBUGGER_Command);

  The command lets you manage the debug server from a shell. It is
  useful when you need to see something in a running system that does
  not start the debug server by default.

  The command is `debugger`. Enter is to see the current status:

   # debugger
   RTEMS debugger is running

  Use the following options with the `start` command to start the
  debug server:

   -v:
    Set trace to verbose

   -R <transport>
    Set the remote transport, currently only `tcp` supported

   -d <device>
    Set the device. For `tcp` this is the listen port for the
    server

   -t <timeout>
    Set the debugger timeout

   -P <priority>
    Set the debug server's priority (classic API)

   -l <output>
    Set the debug server's output. Can be:

      stdout
      stderr
      kernel

    # debugger -v -d 3456 start

   Use `stop` to stop the debugger:

    # debugger stop

2. Register the remote transport with the debugger:

   r = rtems_debugger_register_tcp_remote();
   if (r < 0)
    die("failed");

3. Optionally start the debugger or use the shell command:

   rtems_printer printer;
   rtems_print_printer_fprintf(&printer, stdout);
   r = rtems_debugger_start("tcp", "1122", 3, 1, &printer);
   if (r < 0)
    die("failed");

4. Once running on the target connect with gdb using:

    arm-rtems5-gdb myapp.exe
    GNU gdb (GDB) 9.1
    <content removed>
    (gdb) target remote 192.168.1.200:1122
    Remote debugging using 192.168.1.200:1122
    _User_extensions_Thread_switch (executing=0x0, heir=<optimized out>) 
at /opt/work/rtems/rtems.git/cpukit/include/rtems/score/userextimpl.h:379
    379       if ( node != tail ) {

5. The gdb thread commands can show you what is running and you can 
switch threads:
    (gdb) info thread
    Id   Target Id 
                                                        Frame
    * 1    Thread 1.167837697 (UI1  (0a010001), priority(c:235 r:235), 
stack(s: 65536 a:0xa162a0), state(EV:SUSP)) 
_User_extensions_Thread_switch (executing=0x0, heir=<optimized out>) at 
/opt/work/rtems/rtems.git/cpukit/include/rtems/score/userextimpl.h:379
      2    Thread 1.167837698 (SR02 (0a010002), priority(c:165 r:165), 
stack(s: 16384 a:0xa2ffb8), state(CV:SUSP)) 
_User_extensions_Thread_switch (executing=0x0, heir=<optimized out>) at 
/opt/work/si/rtems/rtems.git/cpukit/include/rtems/score/userextimpl.h:379
    (gdb) thread 2
   [Switching to thread 2 (Thread 1.167837698)]
   #0  _User_extensions_Thread_switch (executing=0x0, heir=<optimized 
out>) at 
/opt/work/si/rtems/rtems.git/cpukit/include/rtems/score/userextimpl.h:379
   379       if ( node != tail ) {

  Thread specific breakpoints is not supported.

6. To debugging application initialisation problems, initialise the 
network stack, start the debugger, then sit in a loop while a volatile 
variable is `false` sleeping for a second. Connect with gdb and set the 
variable to `true`, set any further breakpoints and then `continue`.

Note: This is a software based debugging solution for applications. It 
has limitations on what it can debug and some bugs will effect the debug 
server and it's operation. For driver and hardware debugging a hardware 
based debug solution is best.

I hope this helps.

Chris