using libdebugger
Mario Palomares
palomares.mario14 at gmail.com
Thu Apr 30 16:13:59 UTC 2020
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 (<chrisj at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20200430/51e67cd4/attachment.html>
More information about the users
mailing list