Well, really useful information Chris thanks, no worries about the lack of documentation completely understandable. Just let me ask you some more questions
- 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. - Where do you specify the ip of the GDB server ? - 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? - This one is just for curiosity. What are the rest of header files used for, the ones in "rtems/debugger/" 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. 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. Sorry the pile of questions, Mario El jue., 30 abr. 2020 a las 2:14, Chris Johns (<chr...@rtems.org>) escribió: > 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
