Book Image

Mastering Embedded Linux Programming

By : Chris Simmonds
Book Image

Mastering Embedded Linux Programming

By: Chris Simmonds

Overview of this book

Mastering Embedded Linux Programming takes you through the product cycle and gives you an in-depth description of the components and options that are available at each stage. You will begin by learning about toolchains, bootloaders, the Linux kernel, and how to configure a root filesystem to create a basic working device. You will then learn how to use the two most commonly used build systems, Buildroot and Yocto, to speed up and simplify the development process. Building on this solid base, the next section considers how to make best use of raw NAND/NOR flash memory and managed flash eMMC chips, including mechanisms for increasing the lifetime of the devices and to perform reliable in-field updates. Next, you need to consider what techniques are best suited to writing applications for your device. We will then see how functions are split between processes and the usage of POSIX threads, which have a big impact on the responsiveness and performance of the final device The closing sections look at the techniques available to developers for profiling and tracing applications and kernel code using perf and ftrace.
Table of Contents (22 chapters)
Mastering Embedded Linux Programming
About the Author
About the Reviewers

Core files

Core files capture the state of a failing program at the point that it terminates. You don't even have to be in the room with a debugger when the bug manifests itself. So when you see Segmentation fault (core dumped), don't shrug; investigate the core file and extract the goldmine of information in there.

The first observation is that core files are not created by default, but only when the core file resource limit for the process is non-zero. You can change it for the current shell using ulimit -c. To remove all limits on the size of core files, type the following:

$ ulimit -c unlimited

By default, the core file is named core and is placed in the current working directory of the process, which is the one pointed to by /proc/<PID>/cwd. There are a number of problems with this scheme. Firstly, when looking at a device with several files named core it is not obvious which program generated each one. Secondly, the current working directory of the process may well be in a read...