[OE-core] Debugging using sysroots and GDB

[Richard Purdie]

On Tue, 2016-02-23 at 15:09 +0100, Pascal Bach wrote:
> Currently debugging using sysroots seems to work as long as the work
> folder containing the original source is available.
> Once this work dir is gone the debugger is no longer able to find the
> source code. This is especially confusing if some packages are taken
> from sstate and others are built in the current projects, because for
> some libraries the sources can be found and for others not. It is
> hard at first to figure out the reason why one works and the other
> not.
> 
> In order to make it easier to debug using sysroots I propose to
> modify the how the sysroots is built to do somethins similar to
> rootfs:
> 
> 1. Changing the source reference in the debug symbols to point to the
> source under /usr/src/debug
> 2. Copy the sources into /usr/src/debug under sysroots similar to how
> it is done for a debug rootfs.
> 3. Document that the user needs to add the following to the .gdbinit
> to make it work:
>     ```
>     set sysroot /project/oe/build/tmp/sysroots/<target_sysrtoot>
>     set substitute-path /usr/src/debug
> /project/oe/build/tmp/sysroots/<target_sysrtoot>/usr/src/debug
>     ```
> 
> This would also allow the sysroot to be relocatable as it is kind of
> standalone and everything required to debug is included.
> 
> What do you think? Does this proposal make sense, or did I miss
> something and this is completly unnecessary and there is an easier
> way already working?

It really depends on your view of what the sysroot is used for. We
intentionally strip a variety of things out of it as things work today
basically for size/performance reasons. If we start putting debugging
source in there, it will become huge and this will image the size of
things like eSDK and affect the speed of operations like building from
sstate.

We don't really support debugging from the sysroot. We could talk about
changing that but I suspect people wouldn't like the performance
penalty.

You might ask "ok, can we make it optional?". The trouble with that is
more code paths which people will complain we're not testing and
consequently an increased test matrix and even slower patch merging
cycles.

So the question is, is this something we want to support this way?

Cheers,

Richard