[FE training-materials-updates] Embedded Linux debugging lab update
Michael Opdenacker
michael.opdenacker at free-electrons.com
Wed Dec 10 07:02:29 CET 2014
Repository : git://git.free-electrons.com/training-materials.git
On branch : master
Link : http://git.free-electrons.com/training-materials/commit/?id=cf22be5c3d24e614cd1b8a84ae073227770c086e
>---------------------------------------------------------------
commit cf22be5c3d24e614cd1b8a84ae073227770c086e
Author: Michael Opdenacker <michael.opdenacker at free-electrons.com>
Date: Wed Dec 10 07:01:12 2014 +0100
Embedded Linux debugging lab update
- In particular, no longer needing the ltrace patch
with the version of Buildroot that we use now.
Signed-off-by: Michael Opdenacker <michael.opdenacker at free-electrons.com>
>---------------------------------------------------------------
cf22be5c3d24e614cd1b8a84ae073227770c086e
.../data/0001-ltrace-use-current-master.patch | 106 ---------------------
.../sysdev-application-debugging.tex | 56 ++++-------
2 files changed, 19 insertions(+), 143 deletions(-)
diff --git a/lab-data/embedded-linux/buildroot/data/0001-ltrace-use-current-master.patch b/lab-data/embedded-linux/buildroot/data/0001-ltrace-use-current-master.patch
deleted file mode 100644
index 1494e7e..0000000
--- a/lab-data/embedded-linux/buildroot/data/0001-ltrace-use-current-master.patch
+++ /dev/null
@@ -1,106 +0,0 @@
-From af4692a1d97509c9b82ba31c51f65de4d2380dae Mon Sep 17 00:00:00 2001
-From: Alexandre Belloni <alexandre.belloni at free-electrons.com>
-Date: Thu, 24 Jul 2014 23:54:20 +0200
-Subject: [PATCH] ltrace: use current master
-
-ltrace 0.7.3 is the latest release but it is actually broken on ARM
-since PTRACE_SINGLESTEP emulation has been removed, see:
-
-http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=425fc47adb5bb69f76285be77a09a3341a30799e
-
-It fails with:
-PTRACE_SINGLESTEP: Input/output error
-
-Using master solves that until a new release is made.
-
-gc: removed the libelf dependency, ltrace only works with the
-libelf.so.1 library provided by the elfutils package.
-
-Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>
-Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
----
- package/ltrace/Config.in | 2 +-
- package/ltrace/ltrace-02-arm-plt.patch | 30 ++++++++++++++++++++++++++++++
- package/ltrace/ltrace.mk | 13 +++++++++----
- 3 files changed, 40 insertions(+), 5 deletions(-)
- create mode 100644 package/ltrace/ltrace-02-arm-plt.patch
-
-diff --git a/package/ltrace/Config.in b/package/ltrace/Config.in
-index 3448342..36907b8 100644
---- a/package/ltrace/Config.in
-+++ b/package/ltrace/Config.in
-@@ -2,7 +2,7 @@ config BR2_PACKAGE_LTRACE
- bool "ltrace"
- depends on (BR2_i386 || BR2_arm || BR2_mips || BR2_mipsel \
- || BR2_powerpc || BR2_sparc || BR2_x86_64)
-- select BR2_PACKAGE_LIBELF
-+ select BR2_PACKAGE_ELFUTILS
- help
- Debugging program which runs a specified command until it exits.
- While the command is executing, ltrace intercepts and records
-diff --git a/package/ltrace/ltrace-02-arm-plt.patch b/package/ltrace/ltrace-02-arm-plt.patch
-new file mode 100644
-index 0000000..f130ce8
---- /dev/null
-+++ b/package/ltrace/ltrace-02-arm-plt.patch
-@@ -0,0 +1,30 @@
-+From 04377d28135e351c8d096c4392a493e937416815 Mon Sep 17 00:00:00 2001
-+From: Alexandre Belloni <alexandre.belloni at free-electrons.com>
-+Date: Thu, 24 Jul 2014 23:15:20 +0200
-+Subject: [PATCH] Allow building with uclibc toolchains
-+
-+Unfortunately, uclicbc doesn't define SHT_ARM_ATTRIBUTES in elf.h
-+
-+Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>
-+---
-+ sysdeps/linux-gnu/arm/plt.c | 4 ++++
-+ 1 file changed, 4 insertions(+)
-+
-+diff --git a/sysdeps/linux-gnu/arm/plt.c b/sysdeps/linux-gnu/arm/plt.c
-+index 9e9e37f0c5b0..a0a5795eb9cb 100644
-+--- a/sysdeps/linux-gnu/arm/plt.c
-++++ b/sysdeps/linux-gnu/arm/plt.c
-+@@ -28,6 +28,10 @@
-+ #include "library.h"
-+ #include "ltrace-elf.h"
-+
-++#ifndef SHT_ARM_ATTRIBUTES
-++#define SHT_ARM_ATTRIBUTES 0x70000003
-++#endif
-++
-+ static int
-+ get_hardfp(uint64_t abi_vfp_args)
-+ {
-+--
-+1.9.1
-+
-diff --git a/package/ltrace/ltrace.mk b/package/ltrace/ltrace.mk
-index 99c1af6..48bf7bd 100644
---- a/package/ltrace/ltrace.mk
-+++ b/package/ltrace/ltrace.mk
-@@ -4,13 +4,18 @@
- #
- ################################################################################
-
--LTRACE_VERSION = 0.7.3
--LTRACE_SITE = http://sources.buildroot.net/
--LTRACE_SOURCE = ltrace-$(LTRACE_VERSION).tar.bz2
--LTRACE_DEPENDENCIES = libelf
-+LTRACE_VERSION = 0896ce554f80afdcba81d9754f6104f863dea803
-+LTRACE_SITE = git://anonscm.debian.org/collab-maint/ltrace.git
-+LTRACE_DEPENDENCIES = elfutils
- LTRACE_CONF_OPT = --disable-werror
- LTRACE_LICENSE = GPLv2
- LTRACE_LICENSE_FILES = COPYING
-+LTRACE_AUTORECONF = YES
-+
-+define LTRACE_CREATE_CONFIG_M4
-+ mkdir -p $(@D)/config/m4
-+endef
-+LTRACE_POST_PATCH_HOOKS += LTRACE_CREATE_CONFIG_M4
-
- # ltrace can use libunwind only if libc has backtrace() support
- # We don't normally do so for uClibc and we can't know if it's external
---
-1.9.1
-
diff --git a/labs/sysdev-application-debugging/sysdev-application-debugging.tex b/labs/sysdev-application-debugging/sysdev-application-debugging.tex
index d5bb359..4119fda 100644
--- a/labs/sysdev-application-debugging/sysdev-application-debugging.tex
+++ b/labs/sysdev-application-debugging/sysdev-application-debugging.tex
@@ -1,12 +1,10 @@
-%\subchapter{Remote application debugging}{Objective: Use strace and
-% ltrace to diagnose program issues. Use gdbserver and a
-\subchapter{Remote application debugging}{Objective: Use strace
- to diagnose program issues. Use gdbserver and a
+\subchapter{Remote application debugging}{Objective: Use \code{strace}
+ to diagnose program issues. Use \code{gdbserver} and a
cross-debugger to remotely debug an embedded application}
\section{Setup}
-Go to the \code{$HOME/embedded-linux-labs/debugging} directory.
+Go back to the \code{$HOME/embedded-linux-labs/buildroot} directory.
\section{Debugging setup}
@@ -23,16 +21,12 @@ copied in your target filesystem thanks to the
Buildroot can also help you compile debugging tools. Select the
\code{strace} and \code{ltrace} packages.
-Unfortunately, the latest \code{ltrace} release is quite old and is
-not working on recent ARM kernels. This is the one that will be
-compiled by the Buildroot version you are using. You can apply the
-patch named \code{0001-ltrace-use-current-master.patch} to compile a
-more recent \code{ltrace} version.
-
Now, you can compile and install everything in your root filesystem.
\section{Using strace}
+Now, go to the \code{$HOME/embedded-linux-labs/debugging} directory.
+
\code{strace} allows to trace all the system calls made by a process:
opening, reading and writing files, starting other processes,
accessing time, etc. When something goes wrong in your application,
@@ -41,21 +35,15 @@ you don't have the source code.
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 (you might need to create
-this directory if it doesn't exist yet).
-
-\begin{verbatim}
-arm-linux-gcc -o vista-emulator data/vista-emulator.c
-cp vista-emulator path/to/root/filesystem/root
-\end{verbatim}
+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}
program. It should hang indefinitely!
Interrupt this program by hitting \code{[Ctrl] [C]}.
-Now, running this program again through the strace command and
+Now, running this program again through the \code{strace} command and
understand why it hangs. You can guess it without reading the source
code!
@@ -64,9 +52,7 @@ proceed to another bug, failing with a segmentation fault.
\section{Using ltrace}
-Try to run the program through \code{ltrace}. You may see that
-another library is required to run this utility. Find this library in
-the Buildroot output and add it to your root filesystem.
+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!
@@ -81,9 +67,9 @@ include debugging symbols. This time, just keep it on your workstation,
as you already have the version without debugging symbols on your target.
Then, on the target side, run \code{vista-emulator} under
-\code{gdbserver}. gdbserver will listen on a TCP port for a connection
-from GDB, and will control the execution of vista-emulator according
-to the GDB commands:
+\code{gdbserver}. \code{gdbserver} will listen on a TCP port for a
+connection from \code{gdb}, and will control the execution of
+\code{vista-emulator} according to the \code{gdb} commands:
\begin{verbatim}
gdbserver localhost:2345 vista-emulator
@@ -99,12 +85,12 @@ You can also start the debugger through the \code{ddd} interface:
ddd --debugger arm-linux-gdb vista-emulator
\end{verbatim}
-GDB starts and loads the debugging information from the
+\code{gdb} starts and loads the debugging information from the
\code{vista-emulator} binary that has been compiled with \code{-g}.
Then, we need to tell where to find our libraries, since they are not
present in the default \code{/lib} and \code{/usr/lib} directories on
-your workstation. This is done by setting the GDB \code{sysroot}
+your workstation. This is done by setting the \code{gdb} \code{sysroot}
variable (on one line):
\begin{verbatim}
@@ -112,7 +98,7 @@ variable (on one line):
buildroot-XXXX.YY/output/staging
\end{verbatim}
-And tell gdb to connect to the remote system:
+And tell \code{gdb} to connect to the remote system:
\begin{verbatim}
(gdb) target remote <target-ip-address>:2345
\end{verbatim}
@@ -126,9 +112,9 @@ application.
Then, use \code{gdb} as usual to set breakpoints, look at the source
code, run the application step by step, etc. Graphical versions of
-gdb, such as \code{ddd} can also be used in the same way. In our case,
-we'll just start the program and wait for it to hit the segmentation
-fault:
+\code{gdb}, such as \code{ddd} can also be used in the same way.
+In our case, we'll just start the program and wait for it to hit
+the segmentation fault:
\begin{verbatim}
(gdb) continue
\end{verbatim}
@@ -146,17 +132,13 @@ finding the bug in our application.
During this lab, we learned that...
\begin{itemize}
-\item Compiling an application for the target system is very similar
- to compiling an application for the host, except that the
- cross-compilation introduces a few complexities when libraries are
- used.
\item It's easy to study the behavior of programs and diagnose issues
% 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
- that allows to debug target applications, using a standard GDB
+ that allows to debug target applications, using a standard \code{gdb}
debugger on the development host.
\item It is fine to strip applications and binaries on the target
More information about the training-materials-updates
mailing list