<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 22, 2016 at 9:29 PM, Hongxu Jia <span dir="ltr"><<a href="mailto:hongxu.jia@windriver.com" target="_blank">hongxu.jia@windriver.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
<div>On 03/23/2016 12:49 AM, Bruce Ashfield
wrote:<br>
</div>
<blockquote type="cite">
<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>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" target="_blank"></a><a href="mailto:hongxu.jia@windriver.com" target="_blank">hongxu.jia@windriver.com</a><br>
</span><span>> <mailto:<a href="mailto:hongxu.jia@windriver.com" target="_blank"></a><a href="mailto:hongxu.jia@windriver.com" target="_blank">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>
</div>
</div>
</blockquote>
<br></div></div>
While building kernel, there are many build paths which caused by
macro __FILE__.<br>
Once you invoke marco WARN_ON in kernel/module, there will be a
__FILE__ used.<br>
....<br>
#define WARN_ON(condition)
({ \<br>
int __ret_warn_on =
!!(condition); \<br>
if
(unlikely(__ret_warn_on)) \<br>
__WARN(); \<br>
unlikely(__ret_warn_on); \<br>
})<br>
<br>
#define __WARN() warn_slowpath_null(__FILE__,
__LINE__)<br>
....<br></div></blockquote><div><br></div><div><br></div><div>Aha. Honestly, I've always gotten different paths from the kernel debug info (or many</div><div>applications) via __FILE__, and never considered it much of a problem to go and</div><div>find the source file :) .. but I digress.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
That's why I add -fdebug-prefix-map to kernel build. I original
added a new option<br>
-ffile-prefix-map for gcc to remap __FILE__, and enhance
-fdebug-prefix-map<br>
to replace -ffile-prefix-map to compat with external toolchain.<span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</div>
</blockquote>
<br></span>
If the leaking idea is bad, would you like to accept
'-fdebug-prefix-map' as<br>
kernel's private?<br></div></blockquote><div><br></div><div>Either you patch the kernel, and make it a Kconfig option for the mapping, or we pass it</div><div>in as an intrinsic part of the CC definition, or some variant of those.</div><div><br></div><div>Bruce</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
Or suggestions else to fix the build path in kernel?<span class="HOEnZb"><font color="#888888"><br>
<br>
//Hongxu</font></span><div><div class="h5"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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><br>
> Bruce<br>
><br>
><br>
><br>
> [YOCTO #7058]<br>
><br>
> Signed-off-by: Hongxu Jia <<a href="mailto:hongxu.jia@windriver.com" target="_blank"></a><a href="mailto:hongxu.jia@windriver.com" target="_blank">hongxu.jia@windriver.com</a><br>
</span>> <mailto:<a href="mailto:hongxu.jia@windriver.com" target="_blank">hongxu.jia@windriver.com</a>>><br>
<div>
<div>> ---<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" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
</div>
</div>
> <mailto:<a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a>><br>
<div>
<div>> <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>"Thou shalt not follow the NULL
pointer, for chaos and madness await thee at its end"</div>
</div>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"</div>
</div></div>