Re: [PATCH 01/17] conf/bitbake.conf package.bbclass: fix dbg package not contain sources while -fdebug-prefix-map used

[Mark Hatle <mark.hatle@windriver.com>]

On 4/18/16 11:32 PM, Paul Eggleton wrote:
> On Mon, 18 Apr 2016 13:50:15 Mark Hatle wrote:
>> On 4/18/16 9:16 AM, Andreas Müller wrote:
>>> On Mon, Apr 18, 2016 at 3:55 PM, Burton, Ross <ross.burton@intel.com> 
> wrote:
>>>> On 18 April 2016 at 14:08, Hongxu Jia <hongxu.jia@windriver.com> wrote:
>>>>> If sysroot is required, override DEBUG_FLAGS to remove
>>>>> -fdebug-prefix-map
>>>>
>>>> We should probably get this in the release notes, as many people do
>>>> indeed
>>>> want remote debug to work.
>>>>
>>>> Can you tell gdb the base path to use when looking for symbols?  I've not
>>>> done remote GDB for some time but wouldn't "set substitute-path /
>>>> //my/sysroot/" work?  Or maybe /usr /my/sysroot/usr?
>>>>
>>>> If gdb can't be told then instead of having to replace all of DEBUG_FLAGS
>>>> it would be neat if the prefix mapping variables where in another
>>>> variable that could just be unset.
>>>>
>>>> Ross
>>>
>>> OK I think I could live with removing -fdebug-prefix-map for now.
>>>
>>> A thought: We have the setting IMAGE_GEN_DEBUGFS - I have not yet
>>> tested. As far as I understand it creates an unstripped sysroot and
>>> does not affect target rootfs - is that correct? Does the sysroot
>>> created by IMAGE_GEN_DEBUGFS contain the sources? If yes we could set
>>> that as sysroot for gdb.
>>>
>>> I think one of the problems we have here is that there is no reference
>>> way documented (or it is outdated) how remote debugging is meant to be
>>> performed.
>>
>> Remote debugging is setup to always assume the remote side has access to a
>> debugable sysroot.  This isn't the project's sysroot, since that is
>> transient, but a REAL matching sysroot to the main image.
>>
>> The easiest way to do this is to add the following to your local.conf:
>>    IMAGE_GEN_DEBUGFS = '1'
>>
>> After this, look in your deploy directory and you will see the image to
>> deploy to the target, and also a matching 'debug' chunk that you keep on
>> your local host.  This way you -know- they are always in sync.
>>
>> There is class material from the various Yocto Project Dev Day classes on
>> using this.
> 
> I thought I'd seen this go into the manual but I can't seem to find it; I also 
> can't find said Dev Day class material online. Mark, would you be able to work 
> with Scott R to get this documented both within the variable reference and in 
> a task-oriented manner?
> 
> In the mean time, Jefro - is the recent dev day material available somewhere? 
> I can only find 2014 (ELCE Dusseldorf) under "Training" on the YP website.

(I thought these steps were documented as well, and also were part of the
beginner material.  But I've also not been able to find it -- as I've only got
the advanced class materials for Ireland and San Diego.)


The steps are in the Dusseldorf slides:

http://www.yoctoproject.org/bulk/devday-eu-2014/ypdd14-reyna-iot-hands-on-lab.pdf

Slide 28 shows the old way of producing the debugfs.  The new way is to use the
IMAGE_GEN_DEBUGFS = "1".  You then extract it (and the original rootfs) into a
single directory.  In the slides that directory is called "debugfs".


Start on slide 44.

The setup for GDB (on the host side):

(gdb) set sysroot debugfs
(gdb) set substitute-path /usr/src/debug debugfs/usr/src/debug
(gdb) file debugfs/usr/bin/morseapp

This assumes your CWD is the place with the exracted debugfs (produced by the
IMAGE_GEN_DEBUGFS = "1").

The substitute-path is what allows the (host) to find the matching symbols for
the items.  You simply set:

set substitute-path <piece of target path> <host equivalent>

By using the debugfs, you don't have to set this to 100 different locations, you
can simply use a single location.

--Mark

> Thanks,
> Paul
>