Of course after hitting send, I noticed the example in 7 was missing on step..
:P
On 4/19/16 9:47 AM, Mark Hatle wrote:
> 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
(missing step)
$ cp packages-split/bash/bin/bash <path>/debugfs/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
