<div dir="ltr">Well, really useful information Chris thanks, no worries about the lack of documentation completely understandable.<div>Just let me ask you some more questions<div><br></div><div>- I´am trying to use it on a raspberry pi 2B, is it currently supported, do i have to change something on the snippet of code you showed me?. Note: In the BSP i compiled i have all the debugger header files so y suppose it is supported.</div><div><br></div><div>- Where do you specify the ip of the GDB server ?</div><div><br></div><div>- I don´t understand the rtems_printer usage, shouldn´t the debug server output always go to the debug client instead of the stdout/stderr/kernel?</div><div><br></div><div>- This one is just for curiosity. What are the rest of header files used for, the ones in "rtems/debugger/"</div><div><br></div><div>Regarding a hardware based debugging solution i am also using right now JTAG with OpenOCD but i am experiencing some problems. Once the conection is established I can connect thorught telnet but not from GDB, i still have to investigate on my own, but if I finally i can´t solve i will ask here.</div><div><br></div><div>I would also like to ask you about another thing i couldn´t find on the documentation. Apparently there is a way to set a ser2net daemon which enables you to connect to the target console through a telnet connection. As with the debugger i don´t know how to set it up.</div><div><br></div><div>Sorry the pile of questions,</div></div><div>Mario</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El jue., 30 abr. 2020 a las 2:14, Chris Johns (<<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 29/4/20 6:37 pm, Mario Palomares wrote:<br>
> Hi everybody,<br>
> <br>
> I'have seen in the documentation, Users Manual/Debugging, that there is <br>
> a possibility to do remote debugging with the libdebugger library. But <br>
> there, it only mentions the possibility, it doesn´t explain how to set <br>
> it up.<br>
> I'have searched for some documentation about it and found this:<br>
> <br>
> <a href="https://docs.rtems.org/releases/rtemsdocs-4.7.1/share/rtems/html/rgdb_specs/rgdb_specs00011.html" rel="noreferrer" target="_blank">https://docs.rtems.org/releases/rtemsdocs-4.7.1/share/rtems/html/rgdb_specs/rgdb_specs00011.html</a><br>
> <a href="https://docs.rtems.org/releases/4.5.1-pre3/rtemsdoc/pdf/rtems_gdb.pdf" rel="noreferrer" target="_blank">https://docs.rtems.org/releases/4.5.1-pre3/rtemsdoc/pdf/rtems_gdb.pdf</a><br>
> <br>
> I have also checked the header files in the source tree, but still need <br>
> some guidance.<br>
> <br>
> Could explain a little about this or reference me some useful documentation?<br>
> <br>
<br>
Only a limited number of architectures are supported and some like the <br>
ARM thumb mode are experimental. I do apologise for the lack of <br>
documentation, most of the recent work is unfunded, i.e. ARM support, <br>
and any time I have is spent on the code.<br>
<br>
The set up is simple as the test code in libbsd shows:<br>
<br>
<a href="https://git.rtems.org/rtems-libbsd/tree/testsuite/debugger01/test_main.c" rel="noreferrer" target="_blank">https://git.rtems.org/rtems-libbsd/tree/testsuite/debugger01/test_main.c</a><br>
<br>
Note:<br>
<br>
a) Add `-ldebugger` to your list of libraries when linking your application.<br>
<br>
b) Make sure you have the network running for the TCP transport before <br>
starting the debugger.<br>
<br>
Setup<br>
-----<br>
<br>
1. Optionally add the debugger shell command using:<br>
<br>
rtems_shell_add_cmd_struct(&rtems_shell_DEBUGGER_Command);<br>
<br>
The command lets you manage the debug server from a shell. It is<br>
useful when you need to see something in a running system that does<br>
not start the debug server by default.<br>
<br>
The command is `debugger`. Enter is to see the current status:<br>
<br>
# debugger<br>
RTEMS debugger is running<br>
<br>
Use the following options with the `start` command to start the<br>
debug server:<br>
<br>
-v:<br>
Set trace to verbose<br>
<br>
-R <transport><br>
Set the remote transport, currently only `tcp` supported<br>
<br>
-d <device><br>
Set the device. For `tcp` this is the listen port for the<br>
server<br>
<br>
-t <timeout><br>
Set the debugger timeout<br>
<br>
-P <priority><br>
Set the debug server's priority (classic API)<br>
<br>
-l <output><br>
Set the debug server's output. Can be:<br>
<br>
stdout<br>
stderr<br>
kernel<br>
<br>
# debugger -v -d 3456 start<br>
<br>
Use `stop` to stop the debugger:<br>
<br>
# debugger stop<br>
<br>
2. Register the remote transport with the debugger:<br>
<br>
r = rtems_debugger_register_tcp_remote();<br>
if (r < 0)<br>
die("failed");<br>
<br>
3. Optionally start the debugger or use the shell command:<br>
<br>
rtems_printer printer;<br>
rtems_print_printer_fprintf(&printer, stdout);<br>
r = rtems_debugger_start("tcp", "1122", 3, 1, &printer);<br>
if (r < 0)<br>
die("failed");<br>
<br>
4. Once running on the target connect with gdb using:<br>
<br>
arm-rtems5-gdb myapp.exe<br>
GNU gdb (GDB) 9.1<br>
<content removed><br>
(gdb) target remote <a href="http://192.168.1.200:1122" rel="noreferrer" target="_blank">192.168.1.200:1122</a><br>
Remote debugging using <a href="http://192.168.1.200:1122" rel="noreferrer" target="_blank">192.168.1.200:1122</a><br>
_User_extensions_Thread_switch (executing=0x0, heir=<optimized out>) <br>
at /opt/work/rtems/rtems.git/cpukit/include/rtems/score/userextimpl.h:379<br>
379 if ( node != tail ) {<br>
<br>
5. The gdb thread commands can show you what is running and you can <br>
switch threads:<br>
(gdb) info thread<br>
Id Target Id <br>
Frame<br>
* 1 Thread 1.167837697 (UI1 (0a010001), priority(c:235 r:235), <br>
stack(s: 65536 a:0xa162a0), state(EV:SUSP)) <br>
_User_extensions_Thread_switch (executing=0x0, heir=<optimized out>) at <br>
/opt/work/rtems/rtems.git/cpukit/include/rtems/score/userextimpl.h:379<br>
2 Thread 1.167837698 (SR02 (0a010002), priority(c:165 r:165), <br>
stack(s: 16384 a:0xa2ffb8), state(CV:SUSP)) <br>
_User_extensions_Thread_switch (executing=0x0, heir=<optimized out>) at <br>
/opt/work/si/rtems/rtems.git/cpukit/include/rtems/score/userextimpl.h:379<br>
(gdb) thread 2<br>
[Switching to thread 2 (Thread 1.167837698)]<br>
#0 _User_extensions_Thread_switch (executing=0x0, heir=<optimized <br>
out>) at <br>
/opt/work/si/rtems/rtems.git/cpukit/include/rtems/score/userextimpl.h:379<br>
379 if ( node != tail ) {<br>
<br>
Thread specific breakpoints is not supported.<br>
<br>
6. To debugging application initialisation problems, initialise the <br>
network stack, start the debugger, then sit in a loop while a volatile <br>
variable is `false` sleeping for a second. Connect with gdb and set the <br>
variable to `true`, set any further breakpoints and then `continue`.<br>
<br>
Note: This is a software based debugging solution for applications. It <br>
has limitations on what it can debug and some bugs will effect the debug <br>
server and it's operation. For driver and hardware debugging a hardware <br>
based debug solution is best.<br>
<br>
I hope this helps.<br>
<br>
Chris<br>
</blockquote></div>