module.bbclass: add HOSTCC for out-of-tree modules

Submitted by Vyacheslav Yurkov on Oct. 1, 2020, 1:59 p.m. | Patch ID: 176929

Details

Message ID 20201001135927.721794-1-uvv.mail@gmail.com
State New
Headers show

Commit Message

Vyacheslav Yurkov Oct. 1, 2020, 1:59 p.m.
From: Vyacheslav Yurkov <Vyacheslav.Yurkov@bruker.com>

Module build environment should be aware of native C and C++ compiler's
environment otherwise kernel Makefile might silently fail for some checks.
A particular example is CONFIG_STACK_VALIDATION when CONFIG_UNWINDER_ORC
is used, Makefile tries unsuccessfully locate libelf, even though it's
already available in recipe sysroot.

Signed-off-by: Vyacheslav Yurkov <Vyacheslav.Yurkov@bruker.com>
---
 meta/classes/module.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Patch hide | download patch | download mbox

diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass
index c0dfa35061..8a691922c7 100644
--- a/meta/classes/module.bbclass
+++ b/meta/classes/module.bbclass
@@ -1,6 +1,6 @@ 
 inherit module-base kernel-module-split pkgconfig
 
-EXTRA_OEMAKE += "KERNEL_SRC=${STAGING_KERNEL_DIR}"
+EXTRA_OEMAKE += "KERNEL_SRC=${STAGING_KERNEL_DIR} HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" HOSTCPP="${BUILD_CPP}""
 
 MODULES_INSTALL_TARGET ?= "modules_install"
 MODULES_MODULE_SYMVERS_LOCATION ?= ""

Comments

Bruce Ashfield Oct. 1, 2020, 2:36 p.m.
On Thu, Oct 1, 2020 at 9:59 AM Vyacheslav Yurkov <uvv.mail@gmail.com> wrote:
>
> From: Vyacheslav Yurkov <Vyacheslav.Yurkov@bruker.com>
>
> Module build environment should be aware of native C and C++ compiler's
> environment otherwise kernel Makefile might silently fail for some checks.
> A particular example is CONFIG_STACK_VALIDATION when CONFIG_UNWINDER_ORC
> is used, Makefile tries unsuccessfully locate libelf, even though it's
> already available in recipe sysroot.
>
> Signed-off-by: Vyacheslav Yurkov <Vyacheslav.Yurkov@bruker.com>
> ---
>  meta/classes/module.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass
> index c0dfa35061..8a691922c7 100644
> --- a/meta/classes/module.bbclass
> +++ b/meta/classes/module.bbclass
> @@ -1,6 +1,6 @@
>  inherit module-base kernel-module-split pkgconfig
>
> -EXTRA_OEMAKE += "KERNEL_SRC=${STAGING_KERNEL_DIR}"
> +EXTRA_OEMAKE += "KERNEL_SRC=${STAGING_KERNEL_DIR} HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" HOSTCPP="${BUILD_CPP}""
>

We already ran into this with the main kernel flags, and we don't want
to duplicate them here.

Why aren't what we have in kernel.bbclass working in your scenario ?

Bruce

>  MODULES_INSTALL_TARGET ?= "modules_install"
>  MODULES_MODULE_SYMVERS_LOCATION ?= ""
> --
> 2.25.1
>
>
> 
>
Vyacheslav Yurkov Oct. 1, 2020, 2:47 p.m.
On 01.10.2020 16:36, Bruce Ashfield wrote:
> We already ran into this with the main kernel flags, and we don't want
> to duplicate them here.
>
> Why aren't what we have in kernel.bbclass working in your scenario ?
>
> Bruce
>
Because kernel.bbclass is not pulled in into the environment of 
out-of-tree module recipe. Should it be?
This can easily be checked when you do 'bitbake hello-mod -c devshell' 
and examine $EXTRA_OEMAKE variable.

Vyacheslav
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142999): https://lists.openembedded.org/g/openembedded-core/message/142999
Mute This Topic: https://lists.openembedded.org/mt/77240868/3617530
Group Owner: openembedded-core+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [oe-patchwork@oe-patch.openembedded.org]
-=-=-=-=-=-=-=-=-=-=-=-
Bruce Ashfield Oct. 1, 2020, 2:53 p.m.
On Thu, Oct 1, 2020 at 10:47 AM Vyacheslav Yurkov <uvv.mail@gmail.com> wrote:
>
> On 01.10.2020 16:36, Bruce Ashfield wrote:
> > We already ran into this with the main kernel flags, and we don't want
> > to duplicate them here.
> >
> > Why aren't what we have in kernel.bbclass working in your scenario ?
> >
> > Bruce
> >
> Because kernel.bbclass is not pulled in into the environment of
> out-of-tree module recipe. Should it be?
> This can easily be checked when you do 'bitbake hello-mod -c devshell'
> and examine $EXTRA_OEMAKE variable.

Yes, it should be.

We build out of tree modules in each autobuilder test run, so it is
functional for the most part. I'd be interested to see the reproducing
kernel module and build steps, so they can be built into the tests to
catch this.

But we absolutely do not want to duplicate those flags into this class.

So with a reproducer, we can perhaps shuffle things around and make
sure that both this new case and the old ones continue to work.

Bruce

>
> Vyacheslav
Bruce Ashfield Oct. 1, 2020, 3:05 p.m.
On Thu, Oct 1, 2020 at 10:53 AM Bruce Ashfield via
lists.openembedded.org
<bruce.ashfield=gmail.com@lists.openembedded.org> wrote:
>
> On Thu, Oct 1, 2020 at 10:47 AM Vyacheslav Yurkov <uvv.mail@gmail.com> wrote:
> >
> > On 01.10.2020 16:36, Bruce Ashfield wrote:
> > > We already ran into this with the main kernel flags, and we don't want
> > > to duplicate them here.
> > >
> > > Why aren't what we have in kernel.bbclass working in your scenario ?
> > >
> > > Bruce
> > >
> > Because kernel.bbclass is not pulled in into the environment of
> > out-of-tree module recipe. Should it be?
> > This can easily be checked when you do 'bitbake hello-mod -c devshell'
> > and examine $EXTRA_OEMAKE variable.
>
> Yes, it should be.
>
> We build out of tree modules in each autobuilder test run, so it is
> functional for the most part. I'd be interested to see the reproducing
> kernel module and build steps, so they can be built into the tests to
> catch this.

And by that, I mean more than the warnings about ORC, etc. Since those
have been popping up for some time.

I'm not saying we shouldn't be fixing those, I'm just wondering if
this is an actual build failure, versus the ones we know about.

(and either way, it doesn't change the way we fix it, just that we can
test it better).

Bruce

>
> But we absolutely do not want to duplicate those flags into this class.
>
> So with a reproducer, we can perhaps shuffle things around and make
> sure that both this new case and the old ones continue to work.
>
> Bruce
>
> >
> > Vyacheslav
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
> 
>
Vyacheslav Yurkov Oct. 1, 2020, 3:05 p.m.
On 01.10.2020 16:53, Bruce Ashfield wrote:
> On Thu, Oct 1, 2020 at 10:47 AM Vyacheslav Yurkov <uvv.mail@gmail.com> wrote:
>> On 01.10.2020 16:36, Bruce Ashfield wrote:
>>> We already ran into this with the main kernel flags, and we don't want
>>> to duplicate them here.
>>>
>>> Why aren't what we have in kernel.bbclass working in your scenario ?
>>>
>>> Bruce
>>>
>> Because kernel.bbclass is not pulled in into the environment of
>> out-of-tree module recipe. Should it be?
>> This can easily be checked when you do 'bitbake hello-mod -c devshell'
>> and examine $EXTRA_OEMAKE variable.
> Yes, it should be.
>
> We build out of tree modules in each autobuilder test run, so it is
> functional for the most part. I'd be interested to see the reproducing
> kernel module and build steps, so they can be built into the tests to
> catch this.
>
> But we absolutely do not want to duplicate those flags into this class.
>
> So with a reproducer, we can perhaps shuffle things around and make
> sure that both this new case and the old ones continue to work.
>
> Bruce
>
That's interesting to know. It has been easy to reproduce in 4.x kernel, 
but with 5.x in master it fails silently. So here's what you do with 5.x 
and meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb module

1. Set machine to any x86, e.g. qemux86-64
2. Enable CONFIG_UNWINDER_ORC in the kernel configuration
3. Modify kernel Makefile as follows:
Vyacheslav, [01.10.20 17:01]
index 8b1d5b9017a5..e35da9f9bb75 100644
    endif

4. If HOSTCC is set properly, then you should see "Validation enabled" 
in log.do_compile of hello-mod recipe.

Any hints where autobuilder tests are? Perhaps I could take a look and 
find a way to cover this...

Vyacheslav
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#143001): https://lists.openembedded.org/g/openembedded-core/message/143001
Mute This Topic: https://lists.openembedded.org/mt/77240868/3617530
Group Owner: openembedded-core+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [oe-patchwork@oe-patch.openembedded.org]
-=-=-=-=-=-=-=-=-=-=-=-
Bruce Ashfield Oct. 1, 2020, 3:16 p.m.
On Thu, Oct 1, 2020 at 11:05 AM Vyacheslav Yurkov <uvv.mail@gmail.com> wrote:
>
> On 01.10.2020 16:53, Bruce Ashfield wrote:
> > On Thu, Oct 1, 2020 at 10:47 AM Vyacheslav Yurkov <uvv.mail@gmail.com> wrote:
> >> On 01.10.2020 16:36, Bruce Ashfield wrote:
> >>> We already ran into this with the main kernel flags, and we don't want
> >>> to duplicate them here.
> >>>
> >>> Why aren't what we have in kernel.bbclass working in your scenario ?
> >>>
> >>> Bruce
> >>>
> >> Because kernel.bbclass is not pulled in into the environment of
> >> out-of-tree module recipe. Should it be?
> >> This can easily be checked when you do 'bitbake hello-mod -c devshell'
> >> and examine $EXTRA_OEMAKE variable.
> > Yes, it should be.
> >
> > We build out of tree modules in each autobuilder test run, so it is
> > functional for the most part. I'd be interested to see the reproducing
> > kernel module and build steps, so they can be built into the tests to
> > catch this.
> >
> > But we absolutely do not want to duplicate those flags into this class.
> >
> > So with a reproducer, we can perhaps shuffle things around and make
> > sure that both this new case and the old ones continue to work.
> >
> > Bruce
> >
> That's interesting to know. It has been easy to reproduce in 4.x kernel,
> but with 5.x in master it fails silently. So here's what you do with 5.x
> and meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb module
>
> 1. Set machine to any x86, e.g. qemux86-64
> 2. Enable CONFIG_UNWINDER_ORC in the kernel configuration
> 3. Modify kernel Makefile as follows:
> Vyacheslav, [01.10.20 17:01]
> index 8b1d5b9017a5..e35da9f9bb75 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1058,7 +1058,9 @@ ifdef CONFIG_STACK_VALIDATION
>        echo "int main() {}" | $(HOSTCC) -xc -o /dev/null
> $(HOST_LIBELF_LIBS) -,1,0)
>     ifeq ($(has_libelf),1)
>       objtool_target := tools/objtool FORCE
> +    $(info "Validation enabled")
>     else
> +    $(info "Check failed, disabling stack validation")
>       SKIP_STACK_VALIDATION := 1
>       export SKIP_STACK_VALIDATION
>     endif
>
> 4. If HOSTCC is set properly, then you should see "Validation enabled"
> in log.do_compile of hello-mod recipe.
>

Ah yes.

As in my previous email, those warnings have been around for a bit and
we've just never had a reason to fix them, and in other scenarios,
I've just been explicitly enabling/adding the variables where I need
them. Since (for instance), we can't always assume that HOSTCC is
available on-target, the architecture support, or HOSTCC is the same
as CC, etc, so we want to cover the combinations properly.

The warnings aren't only seen on module build, just a simple 'make
scripts prepare' will show them, so that's enough of a test to see if
they are or aren't picking up the compiler. I wouldn't make these a
failure, just a warning, as they currently are.

Perhaps this is the motivation to do that fixup :D

Bruce

> Any hints where autobuilder tests are? Perhaps I could take a look and
> find a way to cover this...
>
> Vyacheslav