On 03/23/2016 12:49 AM, Bruce Ashfield wrote: > > > On Tue, Mar 22, 2016 at 12:18 PM, Mark Hatle > wrote: > > On 3/22/16 7:21 AM, Bruce Ashfield wrote: > > > > > > On Tue, Mar 22, 2016 at 8:12 AM, Hongxu Jia > > > >> 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 > > >> > > --- > > 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@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"