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