[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>


 .../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
+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
+Then, in the \code{menuconfig} interface, configure the target
+architecture as done previously but configure the toolchain and
+target packages differently:
 \item In \code{Toolchain}:
    \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}:
+	      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}
  \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
-Boot your ARM board over NFS on the filesystem produced with the same
+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:
-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
-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
 \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
-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):
-arm-linux-gnueabihf-gdb vista-emulator
+arm-linux-gdb vista-emulator
 You can also start the debugger through the \code{ddd} interface:
-ddd --debugger arm-linux-gnueabihf-gdb vista-emulator
+ddd --debugger arm-linux-gdb vista-emulator
 \code{gdb} starts and loads the debugging information from the
@@ -135,7 +155,7 @@ variable (on one line):
 (gdb) set sysroot /home/<user>/embedded-linux-labs/debugging/
 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}:
-\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.
+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