[OE-core] [PATCH 02/16] kernel.bbclass: fix buildpath QA issue
Hongxu Jia
hongxu.jia at windriver.com
Wed Mar 23 01:29:23 UTC 2016
On 03/23/2016 12:49 AM, Bruce Ashfield wrote:
>
>
> On Tue, Mar 22, 2016 at 12:18 PM, Mark Hatle <mark.hatle at windriver.com
> <mailto: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>
> > <mailto: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 ?
>
While building kernel, there are many build paths which caused by macro
__FILE__.
Once you invoke marco WARN_ON in kernel/module, there will be a __FILE__
used.
....
#define WARN_ON(condition) ({ \
int __ret_warn_on = !!(condition); \
if (unlikely(__ret_warn_on)) \
__WARN(); \
unlikely(__ret_warn_on); \
})
#define __WARN() warn_slowpath_null(__FILE__, __LINE__)
....
That's why I add -fdebug-prefix-map to kernel build. I original added a
new option
-ffile-prefix-map for gcc to remap __FILE__, and enhance -fdebug-prefix-map
to replace -ffile-prefix-map to compat with external toolchain.
> 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".
>
If the leaking idea is bad, would you like to accept '-fdebug-prefix-map' as
kernel's private?
Or suggestions else to fix the build path in kernel?
//Hongxu
> 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>
> > <mailto: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>
> > <mailto: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/20160323/b4fabfbf/attachment-0002.html>
More information about the Openembedded-core
mailing list