On 3/22/16 11:49 AM, Bruce Ashfield wrote: > > > On Tue, Mar 22, 2016 at 12:18 PM, Mark Hatle <[email protected] > <mailto:[email protected]>> wrote: > > On 3/22/16 7:21 AM, Bruce Ashfield wrote: > > > > > > On Tue, Mar 22, 2016 at 8:12 AM, Hongxu Jia <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> > wrote: > > > > Since CFLAGS CPPFLAGS CXXFLAGS has been unset, variable DEBUG_FLAGS > could > > not been passed to compiler, so we explicitly add DEBUG_FLAGS to CC > to > > replace build path with target path. > > > > > > Can you be more explicit here ? What is typically contained in > DEBUG_FLAGS ? The > > kernel builds its own compiler line and flags, so anything you are > setting from this > > environment, should not be leaking into the kernel build. > > > > .. which leaves me wondering, what exactly is in DEBUG_FLAGS, and how > is it > > actually fixing the QA issue ? > > The specific debug flag in question is being added to remap the on-disk > path to > the path we want the items to look like from a debugging point of view. > > The typical format of DEBUG_FLAGS is something like: > > DEBUG_FLAGS ?= "-g -feliminate-unused-debug-types" > > This was recently updated to include the remapping: > > DEBUG_FLAGS ?= "-g -feliminate-unused-debug-types \ > -fdebug-prefix-map=${WORKDIR}=/usr/src/debug \ > -fdebug-prefix-map=${STAGING_DIR_NATIVE}= \ > -fdebug-prefix-map=${STAGING_DIR_HOST}= \ > > The idea is the WORKDIR is replaced with '/usr/src/debug' inside of the > binary > and any debug symbol references. This makes it much easier for the > system to > work with supplied debug sources/symbols. > > I'm not sure you want to use DEBUG_FLAGS since anything can be put in > there.... > > Application space code should always use the DEBUG_FLAGS, or I think it's > likely > a bug. > > The kernel though should probably define it's own flag(s). Most likely > you'll > want something simple like: > > -fdebug-prefix-map=${WORKDIR}=/usr/src/debug > > > > I can see that. > > What outputs of the kernel build need this remapping ? The userspace parts ? > Something else ?
The mapping affects __FILE__ references, internal dwarf symbols, etc. So you need to have a mapping that covers the source and any intermediate objects. In the general case using WORKDIR (as above) results in: /usr/src/debug/<source> /usr/src/debug/<build> (This isn't right and I'll be commenting on the patch about that.. since it should be wrapped in a package/version...) Typically in YP 2.0 and before, the format was: /usr/src/debug/<recipe>/<version>/[directories] > The point is that we patch the kernel build, or make a specific Kconfig > option, or > something similar to that, versus leaking our build flags into the kernel > build or > "bad things can happen". I agree.. this flag change needs to be unique to the kernel environment. The key thing is that you want the kernel's internal file references __FILE__, dwarf symbols, etc to have the format of an on-target filesystem location that can be filled out. > So I'm sure the solution in the build is the same, but passing flags via a > general > mechanism like I saw in the patch is generally not a good idea. Agree. --Mark > Bruce > > > > Then all of the internal references to WORKDIR will be replaced with > '/usr/src/debug' which cross gdb can 'map' or on-target will actually > look in > that location. (A corresponding '-dbg' package should be provided with > the > matching compilation sources at the local specified.) > > --Mark > > > Bruce > > > > > > > > [YOCTO #7058] > > > > Signed-off-by: Hongxu Jia <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> > > --- > > meta/classes/kernel.bbclass | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/meta/classes/kernel.bbclass > b/meta/classes/kernel.bbclass > > index c3eab50..d357ccf 100644 > > --- a/meta/classes/kernel.bbclass > > +++ b/meta/classes/kernel.bbclass > > @@ -207,7 +207,7 @@ kernel_do_compile() { > > copy_initramfs > > > > > > use_alternate_initrd=CONFIG_INITRAMFS_SOURCE=${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.cpio > > fi > > - oe_runmake ${KERNEL_IMAGETYPE_FOR_MAKE} > ${KERNEL_ALT_IMAGETYPE} > > CC="${KERNEL_CC}" LD="${KERNEL_LD}" ${KERNEL_EXTRA_ARGS} > $use_alternate_initrd > > + oe_runmake ${KERNEL_IMAGETYPE_FOR_MAKE} > ${KERNEL_ALT_IMAGETYPE} > > CC="${KERNEL_CC} ${DEBUG_FLAGS}" LD="${KERNEL_LD}" > ${KERNEL_EXTRA_ARGS} > > $use_alternate_initrd > > if test "${KERNEL_IMAGETYPE_FOR_MAKE}.gz" = > "${KERNEL_IMAGETYPE}"; then > > gzip -9c < "${KERNEL_IMAGETYPE_FOR_MAKE}" > > "${KERNEL_OUTPUT}" > > fi > > @@ -216,7 +216,7 @@ kernel_do_compile() { > > do_compile_kernelmodules() { > > unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE > > if (grep -q -i -e '^CONFIG_MODULES=y$' ${B}/.config); then > > - oe_runmake -C ${B} ${PARALLEL_MAKE} modules > > CC="${KERNEL_CC}" LD="${KERNEL_LD}" ${KERNEL_EXTRA_ARGS} > > + oe_runmake -C ${B} ${PARALLEL_MAKE} modules > CC="${KERNEL_CC} > > ${DEBUG_FLAGS}" LD="${KERNEL_LD}" ${KERNEL_EXTRA_ARGS} > > > > # Module.symvers gets updated during the > > # building of the kernel modules. We need to > > -- > > 1.9.1 > > > > -- > > _______________________________________________ > > Openembedded-core mailing list > > [email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > > > > > > > > > -- > > "Thou shalt not follow the NULL pointer, for chaos and madness await > thee > at its > > end" > > > > > -- > "Thou shalt not follow the NULL pointer, for chaos and madness await thee at > its > end" -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
