mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-04-22 06:32:12 +02:00
Code Issues Packages Projects Releases Wiki Activity

manuals: define proper numbered lists

Browse Source 
Using "#." instead of "1.", "2.", "3.", etc.

(From yocto-docs rev: 11c2585acd0fa6c330702af2359ce5a9e47cde1f)

Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Reported-by: Quentin Schulz <foss+yocto@0leil.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Michael Opdenacker
2022-12-09 19:01:55 +01:00
committed by Richard Purdie
parent 474e071608
commit 6846d4d00b
28 changed files with 347 additions and 347 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
documentation/dev-manual/debugging.rst
View File

@@ -297,11 +297,11 @@ If you are unsure whether a variable dependency is being picked up
automatically for a given task, you can list the variable dependencies
BitBake has determined by doing the following:
1. Build the recipe containing the task::
#. Build the recipe containing the task::
$ bitbake recipename
2. Inside the :term:`STAMPS_DIR`
#. Inside the :term:`STAMPS_DIR`
directory, find the signature data (``sigdata``) file that
corresponds to the task. The ``sigdata`` files contain a pickled
Python database of all the metadata that went into creating the input
@@ -319,7 +319,7 @@ BitBake has determined by doing the following:
the cached task output. The ``siginfo`` files contain exactly the
same information as ``sigdata`` files.
3. Run ``bitbake-dumpsig`` on the ``sigdata`` or ``siginfo`` file. Here
#. Run ``bitbake-dumpsig`` on the ``sigdata`` or ``siginfo`` file. Here
is an example::
$ bitbake-dumpsig ${BUILDDIR}/tmp/stamps/i586-poky-linux/db/6.0.30-r1.do_fetch.sigdata.7c048c18222b16ff0bcee2000ef648b1
@@ -992,7 +992,7 @@ site <https://sourceware.org/gdb/documentation/>`__.
The following steps show you how to debug using the GNU project
debugger.
1. *Configure your build system to construct the companion debug
#. *Configure your build system to construct the companion debug
filesystem:*
In your ``local.conf`` file, set the following::
@@ -1012,7 +1012,7 @@ debugger.
the full filesystem for debugging. Subsequent steps in this procedure
show how to combine the partial filesystem with the full filesystem.
2. *Configure the system to include gdbserver in the target filesystem:*
#. *Configure the system to include gdbserver in the target filesystem:*
Make the following addition in your ``local.conf`` file::
@@ -1021,7 +1021,7 @@ debugger.
The change makes
sure the ``gdbserver`` package is included.
3. *Build the environment:*
#. *Build the environment:*
Use the following command to construct the image and the companion
Debug Filesystem::
@@ -1057,7 +1057,7 @@ debugger.
the actual image (e.g. ``gdb-cross-i586``). The suggestion is usually the
actual name you want to use.
4. *Set up the* ``debugfs``\ *:*
#. *Set up the* ``debugfs``\ *:*
Run the following commands to set up the ``debugfs``::
@@ -1066,7 +1066,7 @@ debugger.
$ tar xvfj build-dir/tmp/deploy/images/machine/image.rootfs.tar.bz2
$ tar xvfj build-dir/tmp/deploy/images/machine/image-dbg.rootfs.tar.bz2
5. *Set up GDB:*
#. *Set up GDB:*
Install the SDK (if you built one) and then source the correct
environment file. Sourcing the environment file puts the SDK in your
@@ -1075,7 +1075,7 @@ debugger.
If you are using the build system, Gdb is located in
`build-dir`\ ``/tmp/sysroots/``\ `host`\ ``/usr/bin/``\ `architecture`\ ``/``\ `architecture`\ ``-gdb``
6. *Boot the target:*
#. *Boot the target:*
For information on how to run QEMU, see the `QEMU
Documentation <https://wiki.qemu.org/Documentation/GettingStartedDevelopers>`__.
@@ -1084,7 +1084,7 @@ debugger.
Be sure to verify that your host can access the target via TCP.
7. *Debug a program:*
#. *Debug a program:*
Debugging a program involves running gdbserver on the target and then
running Gdb on the host. The example in this step debugs ``gzip``:
@@ -1116,7 +1116,7 @@ debugger.
users ``~/.gdbinit`` file. Upon starting, Gdb automatically runs whatever
commands are in that file.
8. *Deploying without a full image rebuild:*
#. *Deploying without a full image rebuild:*
In many cases, during development you want a quick method to deploy a
new binary to the target and debug it, without waiting for a full