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
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
