[OE-core] Debugging using sysroots and GDB

[Pascal Bach]

> 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.

>From my point of view debugging from sysroots is not mandatory if I can find a suitable alternative.
One thing I want to avoid is to install -dbg packages to my image.

What I currently do is the following:

1. Enable Debugfs generation using: `IMAGE_GEN_DEBUGFS = "1"`
2. Switch debug split style to: `PACKAGE_DEBUG_SPLIT_STYLE = "debug-file-directory"`

After building the image I end up with a rootfs and a rootfs-dbg

3. Extract both rootfs and rootfs-dbg somewhere (/home/projects)
4. Setup gdb with the following .gdbinit:

```
set sysroot /home/projects/rootfs
set debug-file-directory /home/projects/rootfs-dbg/usr/lib/debug
set substitute-path /usr/src/debug /home/projects/rootfs-dbg/usr/src/debug
```

With this setup I'm able to debug trough all libraries on the system.
So so far so good.

However for this to work I need to change the `PACKAGE_DEBUG_SPLIT_STYLE` to a non default and this made me wonder if I missed something.
- Is there a way to get this setup working with the default ".debug" style of OE?
- If not why is the .debug style the default instead of "debug-file-directory"?
- Is there any documentation? I was unable to find anything more than [1] in the Yocto Mega manual.
- Is there some best practice I missed?

[1] http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#platdev-gdb-remotedebug-setup


> 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.
Ok if this is not supported is there any documentation on whats the recommended debugging method?
>
> 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.
I agree, there should only be one recommended and supported way to do debugging and this way should be well documented.
>
> So the question is, is this something we want to support this way?
>
> Cheers,
>
> Richard
Pascal