Yocto - 使用Yocto开发嵌入式Linux系统_11 调试Yocto项目

Debugging with the Yocto Project

The debug process is an essential step in every development cycle. In this chapter, we will learn how to configure Poky to help us with the debugging process; for example, how we can configure our system to provide the tools needed for a remote debug using the Gnu DeBugger (GDB), how we can track our changes using buildhistory, and how we can use handy debug tools, such as oe-pkgdata-util, bitbake-getvar, and devshell.

1, Differentiating metadata and application debugging

在深入了解调试细节之前，我们需要了解调试的不同类型，如元数据调试和运行时代码调试。

Before we delve into the details of debugging, we need to realize that there are different types of debugging, such as metadata and runtime code debugging.

元数据调试是为了确保 BitBake 任务的行为与我们的目标一致，并在不一致时找出罪魁祸首。例如，可能需要修改配方以启用某个功能。在这种情况下，我们可以使用 BitBake 在主机中生成的多个日志文件来帮助追踪相关任务的执行路径。

Metadata debugging is needed to ensure that the behavior of BitBake’s tasks aligns with our goals and to identify the culprit when it’s not aligned. For example, a recipe may need to be fixed to enable a feature. In such a case, we can use several log files generated by BitBake in the host to help trace the execution path of the involved task.

另一方面，调试运行时代码更为自然，因为它与应用程序、库或内核的典型开发周期基本相同。根据我们要解决的问题，正确的工具可能从调试器到代码工具（例如，添加调试打印）不等。

On the other hand, debugging runtime code is more natural as it is essentially the same as the typical development cycle of an application, a library, or a kernel. Depending on the issue we are seeking to resolve, the right tool to help may vary from a debugger to code instrumentation (for example, adding debug prints).

2, Tracking image, package, and SDK contents

要确保我们拥有映像、软件包和软件开发工具包 (SDK) 以及预期内容，最简单的方法就是使用构建历史机制。

The easiest way to ensure we have the image, packages, and software development kit (SDK), along with the expected contents, is to use the buildhistory mechanism.

当配方更新到新版本或代码发生变化时，可能会影响生成软件包的内容，进而影响映像或 SDK。

When a recipe is updated for a new version or has its code changed, it may influence the contents of the generated packages and, consequently, the image or SDK.

Poky 要处理许多配方，而图像或 SDK 往往有数十或数百个软件包。因此，跟踪软件包内容可能很有难度。帮助完成这项任务的 Poky 工具是 buildhistory。

Poky deals with many recipes and images or SDKs frequently have tens or hundreds of packages. Therefore, it may be challenging to track the package contents. The Poky tool that helps in this task is buildhistory.

buildhistory，顾名思义，就是记录 Poky 使用过程中构建的多个工件的内容历史。它跟踪软件包、图像和 SDK 的构建及其内容。

buildhistory, as the name suggests, keeps a history of the contents of several artifacts built during the use of Poky. It tracks package, image, and SDK building and their contents.

要在系统中启用构建历史，我们需要在 build/conf/local.conf 文件中添加以下代码行：

To enable buildhistory in our system, we need to add the following lines of code in our build/conf/local.conf file:

[ Figure 10.1 – How to enable buildhistory support ]

INHERIT 方法将 buildhistory 类钩子包含在构建过程中。同时，BUILDHISTORY_COMMIT 这一行能让 BitBake 为每一个新软件包、镜像或 SDK 的构建在 buildhistory 仓库中创建一个新的 Git 提交。通过 Git 提交，跟踪工作就像在两个提交之间使用 git diff 一样简单。数据以文本文件的形式保存在 build/buildhistory 目录下，方便使用。

The INHERIT method includes the buildhistory class hooks in the building process. At the same time, the BUILDHISTORY_COMMIT line enables BitBake to create a new Git commit in the buildhistory repository for every new package, image, or SDK build. The Git commit makes tracking as simple as using git diff between two commits. The data is stored under the build/buildhistory directory as text files for ease of use.

Poky 提供了一个名为 “buildhistory-diff ”的工具，能以更简洁的方式输出两个构建历史状态之间的差异，这在检查变更时非常有用。buildhistory-diff 工具能更有意义地输出任意两个 Git 修订版本之间的差异。

Poky provides a utility that outputs the difference between two buildhistory states, called buildhistory-diff, in a more concise way, which is very useful when checking for changes. The buildhistory-diff utility outputs the difference between any two Git revisions more meaningful