On 4/19/16 9:11 AM, Andreas Müller wrote:
> thanks a lot for your efforts. Do I understand this right: You suggest
> to use build sysroot (on my own risk - as I did before) and make gdb
> happy by linking sources?
>
> Problem I see is that we have multiple package archs e.g
> ARM/ARMThumb/Machine so ${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}
> expands to multiple paths. But a script symlinking all together + set
> substitute-path might help here...
>
> I will play around with this in the later...
>
> Andreas
>
See Yocto Project bug #9481:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=9481
Below are the steps that I have added that I hope will be documented in the YP
2.1 documentation. (This matches current master.)
I just went through and verified the steps on my local machine. As noted, there
is currently a bug in the debugfs creation. RP helped me fix the 'rpm' case, but
it appears ipkg support is broken in some way.
1. Configure your build system to construct the companion debug filesystem
In the local.conf:
IMAGE_GEN_DEBUGFS = '1'
IMAGE_FSTYPES_DEBUGFS = 'tar.bz2'
The options above will cause the system to generate a special companion
filesystem fragment, that contains the matching source and debug symbols to your
deployable filesystem. It does this by looking at what is in the deployed
filesystem, and pulling the corresponding -dbg packages.
The companion debug filesystem is NOT a complete filesystem, but only contains
the debug fragements. It must be combined with the full filesystem for
debugging. (Later steps will show this.)
2. Configure the system to include gdbserver in the target filesystem
In the local.conf (or an image recipe):
IMAGE_INSTALL_append = “ gdbserver"
3. Build the environment
Construct the image (and companion Debug Filesystem)
bitbake <image>
Build the cross GDB component and make it available for debugging
Build the SDK that matches the image (this is best for a production build for
later debugging, especially during long term maintenance)
bitbake -c populate_sdk <image>
or
Build the minimal toolchain components that match the target (this is smaller
then a typical SDK and only contains a minimal set of components to build simple
test applications, as well as run the debugger)
bitbake meta-toolchain
or
Build gdb itself within the build system (this produces a temporary copy of
cross-gdb that can be used for debugging during development. It is the quickest
approach, but the other methods are better for long term maintenance
strategies.)
bitbake gdb-cross-<arch>
(Note: If you run bitbake gdb-cross, the system will give you a suggestion like
gdb-cross-i586, the suggestion is likely the actual name you want to use.)
4. Setup your environment
4.1 Setup the debugfs
$ mkdir debugfs
$ cd debugfs
$ tar xvfj <build dir>/tmp-glibc/deploy/images/<machine>/<image>.rootfs.tar.bz2
$ tar xvfj <build
dir>/tmp-glibc/deploy/images/<machine>/<image>-dbg.rootfs.tar.bz2
4.2 Setup GDB
Install the SDK (if you built one) and source the correct environment file. This
will put it in your path.
if using the build system gdb will be in
<build>/<tmp>/sysroots/<host>/usr/bin/<arch>/<arch>-gdb
5. Boot the target
For QEMU, <link to runqemu docs…>
(verify that your host can access the target via TCP)
6. Debug a program
6.1 Run gdbserver on the target, such as:
(We’ll debug gzip in this example, see gdbserver docs for additional options)
root@qemux86:~# gdbserver localhost:1234 /bin/gzip —help
6.2 On the host, run gdb, configure it and connect to the target:
$ cd <directory holding the debugfs dir>
$ <arch>-gdb
(gdb) set sysroot debugfs
(gdb) set substitute-path /usr/src/debug debugfs/usr/src/debug
(gdb) target remote <ip of target>:1234
At this point everything should automatically load (matching binaries, symbols
and headers.)
Note: the gdb ‘set’ commands above can be placed into the users ~/.gdbinit GDB
will automatically run whatever commands are in that file when it is started.
7. 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 image build.
One approach to this is to build the component you want to debug. Then directly
copy the executable to BOTH the target and the host ‘debugfs’. If the binary is
processed through the debug splitting in OE, you should also copy the debug
items (the .debug contents and corresponding /usr/src/debug) from the work dir.
Such as:
$ bitbake bash
$ bitbake -c devshell bash
$ cd ..
$ scp packages-split/bash/bin/bash <target>:/bin/bash
$ cp -a packages-split/bash-dbg/* <path>/debugfs
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
