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

Richard Purdie richard.purdie at linuxfoundation.org
Mon Apr 18 14:51:14 UTC 2016


On Mon, 2016-04-18 at 16:16 +0200, 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.

FWIW I do believe the prefix mapping variables are the right thing to
do, it makes sense that the paths in the -dbg files should be /usr/src/
rather than some build time path. We've aimed to do that for a long
time, first using debugedit and more recently directly when compiling
rather than editing later.

We do need to figure out how to explain that to gdb, or if that can't
be made to work, even consider patching gdb and upstreaming the patch
such that it can look at a sysroot and work correctly.

I think it comes down to more people getting involved as we're
struggling to do everything with the current people and as I've said in
other threads, its also aboutbetter test cases so that when something
regresses that people care about we do get to know sooner.

Cheers,

Richard





More information about the Openembedded-core mailing list