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

[Mark Hatle]

On 4/18/16 4:05 PM, Andreas Müller wrote:
> On Mon, Apr 18, 2016 at 8:50 PM, Mark Hatle <mark.hatle at windriver.com> 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 at intel.com> wrote:
>>>>
>>>> On 18 April 2016 at 14:08, Hongxu Jia <hongxu.jia at 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.

Remote (target from host) is setup to always assume the -host- side has access
to a debuggable sysroot.  The target -never- needs access, unless you are trying
to run GDB on the target.

> Just that I get this right: remote = target? If yes: Where do you get
> this from? Or - have you ever run a remote session with files taken
> from target? I have: see caffeine/colleagues section below.
>> This isn't the project's sysroot, since that is transient,
>> but a REAL matching sysroot to the main image.
> If you say transient: Do you mean status of last build. Isn't that
> what I am usually looking for when debugging?

It's transient.  There is no direct correlation between the contents of the
image you are booting and the sysroot directory int he project/tmp/sysroot area.
 The files MIGHT be related, but they are not the same.  The build project is
only setup for actually building software.

To debug, you must you the -dbg packages that are created as part of the build.
 Using the IMAGE_GEN_DEBUGFS automates this process.  Or you can individually
grab (and unpack) the -dbg for the components you wish to debug.

>> The easiest way to do this is to add the following to your local.conf:
>>    IMAGE_GEN_DEBUGFS = '1'
> This exactly what I've asked for in my previous mail - further comments below.
>>
>> 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.
> You really want me to wait for building an full image after each
> modification - I will either die for caffeine overdose or my
> colleagues will kill me...

How big is your filesystem?  Typically when I make a small change, it only takes
me minutes to build a filesystem.. (I'm roughly similar to the core-image-base.)
 I'm not changing key things like the toolchain or glibc, I'm changing
individual applications with few downstream dependencies.

You can always build the component by itself and simply pull the -dbg components
out if you want.  That is certainly a short cut method to this.

The non-dbg have the correct versions for deployment for runtime, while the -dbg
has the corresponding debug information.  The sysroot though is not the right
place for this, if you want to work around the system use the actual work
location for the components themselves and copy the pieces from there.

>>
>> There is class material from the various Yocto Project Dev Day classes on using
>> this.
>>
>>
>> The alternative is tell GDB itself to map directories.  I don't remember offhand
>> the right option, but GDB supports remapping a directory reference to an actual
>> directory.  It should be pretty simple to re-map it -- but due to the transient
>> nature of the sysroot directory in the build, I don't recommend doing it this way.
>>
> We are using remote debugging with build sysroot almost daily and we
> do that since we use openembedded. The more I learn here it seems
> nobody else does remote debugging. How do you fix bugs?

I do remote debugging all the time, note -- for much of my work I'm still on
2.0.  But the design of 2.1 (master) actually makes this easier then before, as
all of the file references are finally correct -- instead of a mismatched set of
target and host dependencies.

I -always- use the -dbg versions when doing local (on target) or remote (host to
target) debugging.  It takes no additional time, and it's easy to shortcut as I
mentioned above.

The sysroot is only appropriate for compiling against.

> I'll remove -fdebug-prefix-map and wait till remote debugging breaks
> again - maybe then completely. That scares me as I am loosing the
> possiblity to start a remote debug session on an productive image
> within seconds.

Without the prefix maps, you won't get functional -dbg packages for remote
debugging of deployed production systems.

This is really the key here, we facilitate both development -and- production
remote debug.  I don't know of any other (embedded) build system that is
designed with production remote debug built in.  You never have to deploy
symbols to your production images, but yet you can still cross debug them by
simply keeping a copy of the -dbg (and as of recently the corresponding debugfs
image.)  This ensures the code is not only debugable today, but in the future
when your product has been deployed for a long time.

--Mark

> Andreas
>