[OE-core] [PATCH 02/16] kernel.bbclass: fix buildpath QA issue

[Bruce Ashfield]

On Tue, Mar 22, 2016 at 12:18 PM, Mark Hatle <mark.hatle at windriver.com>
wrote:

> On 3/22/16 7:21 AM, Bruce Ashfield wrote:
> >
> >
> > On Tue, Mar 22, 2016 at 8:12 AM, Hongxu Jia <hongxu.jia at windriver.com
> > <mailto:hongxu.jia at windriver.com>> 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 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".

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.

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 <hongxu.jia at windriver.com
> >     <mailto:hongxu.jia at windriver.com>>
> >     ---
> >      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
> >     Openembedded-core at lists.openembedded.org
> >     <mailto:Openembedded-core at lists.openembedded.org>
> >     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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160322/784be5e5/attachment-0002.html>