You are looking at the HTML representation of the XML format.
HTML is good for debugging, but is unsuitable for application use.
Specify the format parameter to change the output format.
To see the non HTML representation of the XML format, set format=xml.
See the complete documentation, or
API help for more information.
<allpages gapcontinue="Reset_lost_root_password" />
<page pageid="226" ns="0" title="Remote debugging">
<rev contentformat="text/x-wiki" contentmodel="wikitext" xml:space="preserve">Debugging on a tiny target system may be impossible, because there are no room for the gdb and all the source and binary files on the target system. Luckily remote debugging is available.
There are two (at least) options: DDD or Eclipse.
DDD is a gui for gdb, the GNU debugger. DDD might be available in Cygwin, I don't know. But it is available in all decent Linux distributions.
There are some prerequisites:
* There shall be opened a port for connecting on the target, if a firewall is installed on the target
* The source shall be available on the debugging host
* The gdbserver shall be included on the target system (use make menuconfig)
When the code has been compiled and transferred to the target host start the remote gdbserver on the target:
]$ gdbserver <host-to-expect-connection-from>:<port-number> <program>
]$ gdbserver 10.1.18.73:11000 myprogram
Remember to look up options on the man page!
==On the devhost==
Fire up your debugging environment, i.e. DDD or Eclipse.
Now on the debugging host start DDD. In the command window below type in:
target extended-remote <target-host>:<port-number> <programme>
''(gdb)'' target 10.1.18.210:11000 myprogram
In the console where you've started the gdbserver you should now see that a remote debugger has connected.
Remote debugging from host 10.1.18.73
Next open the executable in the DDD using the file command:
The source shall open in the upper window.
Set a breakpoint either by continuously right-click on the line you want the breakpoint or by typing
Now run the program using the small window with the Run, Interrupt, Step,... buttons or typing '''run''' in the lower window.
You can single step by clicking on the '''Step''' button or by typing '''step''' in the lower window.
Try the different possibilities - its almost like using the built-in debugger in Eclipse (which by the way is also gdb :-) ).
In order to setup Eclipse as a debug station follow these instructions:
First setup the debug configuration as shown.
In the debugger tab choose gdbserver debugger.
Finally set-up the communication in the Connection tab.
<page pageid="865" ns="0" title="Remote monitoring">
<rev contentformat="text/x-wiki" contentmodel="wikitext" xml:space="preserve">Sometimes it can be difficult to determine why a network application doesn't work as expected. Wireshark and Tcpdump are two utilities that can help you monitor the packets going back and forth between two computers.
tcpdump can capture packets on the network interface and output the caputred data to the console - or to a file. (''See man tcpdump'')
Wireshark is a graphical program showing the captured data in a easily readable way. A powerful tool. See more over at [https://www.wireshark.org/]
Wireshark can read dumps made by tcpdump, so on your development board without graphical display you can set-up tcpdump to dump captured packets into a file. Wireshark can read the output file from tcpdump if you move to your development host.
If you have a network connection to your development board you can watch the traffic live by issuing a command like this:
$] ssh root@target_IP_address -p 22 tcpdump -U -s0 'not port 22' -i enp6s0 -w - | wireshark-qt -k -i -
What this command does is that it creates a '''SSH''' connection to the target on '''target_IP_address''' and normally it is port '''22''' ''ssh'' listens on, but you may have configured it to listen on another port. (''ssh root@target_IP_address -p 22''). It may be convienien to have a passwordless, i.e. using your ssh keys, so you don't have to login every time.
Over at the target we execute tcpdump with a number of commandline arguments of which two are of interest (''tcpdump -U -s0 'not port 22' -i enp6s0 -w -''): The port number that the ssh connection is made on (typical port 22) - we don't want to have that traffic to clutter up our dump. Second point of interest is the ethernet adapter, here it is '''enp6s0''', but it could also be like '''eth0''' or similar.
<source lang=bash>ip a </source>
to determine the name of the interface to listen to on the development board.
The final dash (-) before the pipe (|) is a redirection of the standard output to the pipe and, as you can see, wireshark reads from what comes through the pipe. The -k option tells Wireshark to start immediately. The standard output data, form tcpdump, is automagically sent over the ssh connection back to the host and piped into wireshark.
Note: The graphical version of Wireshark comes on some systems in either ''wireshark-gtk'' or ''wireshark-qt'' for GTK based desktops (like GNOME) or qt base desktops (like KDE) or on other systems just as wireshark. Find out which one is available for you.</rev>