[FE training-materials-updates] Updates to the embedded application debugging lab
Michael Opdenacker
michael.opdenacker at free-electrons.com
Thu Nov 9 06:56:39 CET 2017
Repository : git://git.free-electrons.com/training-materials.git
On branch : master
Link : http://git.free-electrons.com/training-materials/commit/?id=dd8185315f0088ed48717665c25c656e19ae4695
>---------------------------------------------------------------
commit dd8185315f0088ed48717665c25c656e19ae4695
Author: Michael Opdenacker <michael.opdenacker at free-electrons.com>
Date: Thu Nov 9 06:54:18 2017 +0100
Updates to the embedded application debugging lab
- ltrace is broken in the uClibc version that
we use in the Crosstool-ng toolchain.
- gdbserver is broken in the Linaro 2017.02 toolchain
- As a consequence, we used a Free Electrons (buildroot built) toolchain
instead, which works like a charm!
- We stop instructing to build debugging tools during toolchain
creation. This saves time.
Signed-off-by: Michael Opdenacker <michael.opdenacker at free-electrons.com>
>---------------------------------------------------------------
dd8185315f0088ed48717665c25c656e19ae4695
.../sysdev-application-debugging.tex | 72 ++++++++++++++--------
labs/sysdev-toolchain/sysdev-toolchain.tex | 11 ++--
2 files changed, 51 insertions(+), 32 deletions(-)
diff --git a/labs/sysdev-application-debugging/sysdev-application-debugging.tex b/labs/sysdev-application-debugging/sysdev-application-debugging.tex
index 6f94658..ef88086 100644
--- a/labs/sysdev-application-debugging/sysdev-application-debugging.tex
+++ b/labs/sysdev-application-debugging/sysdev-application-debugging.tex
@@ -9,28 +9,40 @@ Create an \code{nfsroot} directory.
\section{Debugging setup}
-Because of issues in {\em gdb} in the toolchain compiled by Crosstool-NG,
-we will use a different toolchain in this lab. We will also
-use a different version of Buildroot (which is known to make this lab
-work).
+Because of issues in {\em gdb} and {\em ltrace} in the uClibc version
+that we are using in our toolchain, we will use a different toolchain
+in this lab, based on {\em glibc}.
-Experimenting with multiple toolchains is also good experience!
+As {\em glibc} has more complete features that lighter libraries,
+it looks like a a good idea to do your application debugging work
+with a {\em glibc} toolchain first, and then switch to lighter libraries
+once your application and software stack is production ready.
-Download Buildroot 2016.02 and extract its tarball into
-\code{$HOME/embedded-linux-labs/debugging}. Then, copy the
-configuration of the previous Buildroot build (\code{.config} file)
-into the new Buildroot source directory.
+Extract the 2017.08.x sources into the current directory.
-Then, in \code{menuconfig}, configure the target architecture as
-done previously but configure the toolchain and target packages
-differently:
+Then, in the \code{menuconfig} interface, configure the target
+architecture as done previously but configure the toolchain and
+target packages differently:
\begin{itemize}
\item In \code{Toolchain}:
\begin{itemize}
\item \code{Toolchain type}: \code{External toolchain}
- \item \code{Toolchain}: \code{Linaro ARM 2015.11}
+ \item \code{Toolchain}: \code{Custom Toolchain}
\item \code{Toolchain origin}: \code{Toolchain to be downloaded and installed}
+ \item \code{Toolchain URL}:
+\code{http://toolchains.free-electrons.com/downloads/releases/toolchains/armv7-eabihf/tarballs/armv7-eabihf--glibc--bleeding-edge-2017.08-rc2-5-g5c1b185-1.tar.bz2}\\
+ You can easily choose such a toolchain on
+ \url{http://toolchains.free-electrons.com} by selecting the
+ architecture, the C library and the compiler version you need.
+ While you can try with other versions, the above toolchain
+ is known to make this lab work.
+ \item \code{External toolchain gcc version}: \code{7.x}
+ \item \code{External toolchain kernel headers series}: \code{4.9.x}
+ \item \code{External toochain C library}: \code{glibc/eglibc}
+ \item Select \code{Toolchain has SSP support?}
+ \item Select \code{Toolchain has RPC support?}
+ \item Select \code{Toolchain has C++ support?}
\item Select \code{Copy gdb server to the Target}
\end{itemize}
\item \code{Target packages}
@@ -46,14 +58,14 @@ differently:
Now, build your root filesystem.
Go back to the \code{$HOME/embedded-linux-labs/debugging} directory
-and extract the \code{buildroot-2016.02/output/images/rootfs.tar}
+and extract the \code{buildroot-2017.08.x/output/images/rootfs.tar}
archive in the \code{nfsroot} directory.
-Update the \code{/etc/exports} file and restart the
+Add this directory to the \code{/etc/exports} file and restart
\code{nfs-kernel-server}.
-Boot your ARM board over NFS on the filesystem produced with the same
-kernel.
+Boot your ARM board over NFS on this new filesystem, using the same
+kernel as before.
\section{Using strace}
@@ -69,13 +81,13 @@ you don't have the source code.
Update the PATH:
\footnotesize
\begin{verbatim}
-export PATH=$HOME/embedded-linux-labs/debugging/buildroot-2016.02/output/host/usr/bin:$PATH
+export PATH=$HOME/embedded-linux-labs/debugging/buildroot-2017.08.x/output/host/bin:$PATH
\end{verbatim}
\normalsize
-With your cross-compiling toolchain, compile the
-\code{data/vista-emulator.c} program, strip it with
-\code{arm-linux-gnueabihf-strip}, and copy the resulting binary to the
+With your cross-compiling toolchain
+compile the \code{data/vista-emulator.c} program, strip it with
+\code{arm-linux-strip}, and copy the resulting binary to the
\code{/root} directory of the root filesystem.
Back to target system, try to run the \code{/root/vista-emulator}
@@ -97,6 +109,14 @@ Now run the program through \code{ltrace}.
Now you should see what the program does: it tries to consume as much
system memory as it can!
+Also run the program through \code{ltrace -c}, to see what function call
+statistics this utility can provide.
+
+It's also interesting to run the program again with \code{strace}. You
+will see that memory allocations translate into \code{mmap()} system
+calls. That's how you can recognize them when you're using
+\code{strace}.
+
\section{Using gdbserver}
We are now going to use \code{gdbserver} to understand why the program
@@ -115,14 +135,14 @@ connection from \code{gdb}, and will control the execution of
gdbserver localhost:2345 vista-emulator
\end{verbatim}
-On the host side, run \code{arm-linux-gnueabihf-gdb} (also found in your toolchain):
+On the host side, run \code{arm-linux-gdb} (also found in your toolchain):
\begin{verbatim}
-arm-linux-gnueabihf-gdb vista-emulator
+arm-linux-gdb vista-emulator
\end{verbatim}
You can also start the debugger through the \code{ddd} interface:
\begin{verbatim}
-ddd --debugger arm-linux-gnueabihf-gdb vista-emulator
+ddd --debugger arm-linux-gdb vista-emulator
\end{verbatim}
\code{gdb} starts and loads the debugging information from the
@@ -135,7 +155,7 @@ variable (on one line):
\begin{verbatim}
(gdb) set sysroot /home/<user>/embedded-linux-labs/debugging/
-buildroot-XXXX.YY/output/staging
+buildroot-2017.08.x/output/staging
\end{verbatim}
And tell \code{gdb} to connect to the remote system:
@@ -170,7 +190,7 @@ During this lab, we learned that...
% without even having the source code, thanks to strace and ltrace.
without even having the source code, thanks to strace.
-\item You can leave a small \code{gdbserver} program (300 KB) on your target
+\item You can leave a small \code{gdbserver} program (about 300 KB) on your target
that allows to debug target applications, using a standard \code{gdb}
debugger on the development host.
diff --git a/labs/sysdev-toolchain/sysdev-toolchain.tex b/labs/sysdev-toolchain/sysdev-toolchain.tex
index 30a967d..377c5cd 100644
--- a/labs/sysdev-toolchain/sysdev-toolchain.tex
+++ b/labs/sysdev-toolchain/sysdev-toolchain.tex
@@ -105,13 +105,12 @@ In \code{C-library}:
In \code{Debug facilities}:
\begin{itemize}
-\item Make sure that \code{gdb}, \code{strace} and \code{ltrace}
- are enabled.
-\item Remove the remaining option: \code{duma}).
-\item In \code{gdb} options, make sure that the \code{Cross-gdb} and
- \code{Build a static gdbserver} options are enabled; the other
- options are not needed.
+\item Remove all options.
\end{itemize}
+Some of these options will be useful in a real toolchain, but in our
+labs, we will do debugging work with another toolchain anyway.
+Hence, not compiling debugging features here will reduce toolchain
+building time.
Explore the different other available options by traveling through the
menus and looking at the help for some of the options. Don't hesitate
More information about the training-materials-updates
mailing list