On Tue, Mar 22, 2016 at 9:29 PM, Hongxu Jia <[email protected]> wrote:
> On 03/23/2016 12:49 AM, Bruce Ashfield wrote: > > > > On Tue, Mar 22, 2016 at 12:18 PM, Mark Hatle <[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]>[email protected] >> > <mailto: <[email protected]>[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 ? > > > 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__) > .... > Aha. Honestly, I've always gotten different paths from the kernel debug info (or many applications) via __FILE__, and never considered it much of a problem to go and find the source file :) .. but I digress. > > 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? > Either you patch the kernel, and make it a Kconfig option for the mapping, or we pass it in as an intrinsic part of the CC definition, or some variant of those. Bruce > > 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 < <[email protected]> >> [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]> >> > 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" > > > -- "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
