samples/kdbus/kdbus-workers.c and cross compiling MIPS

DISCUSSION Paul Gortmaker 5 participants 11 messages Jul 29, 2015 – Aug 3, 2015

Subsystems (2)

Linux-next tree MIPS

lore

Share & tools

lore

Paul Gortmaker

author

2015-07-29 16:19 UTC #0 lore raw

Hi David,

Does it make sense to build this sample when cross compiling?

The reason I ask is that it has been breaking the linux-next build of allmodconfig for a while now, with:

HOSTCC samples/kdbus/kdbus-workers
samples/kdbus/kdbus-workers.c: In function ‘prime_new’:
samples/kdbus/kdbus-workers.c:934:18: error: ‘__NR_memfd_create’ undeclared (first use in this function)

  p->fd = syscall(__NR_memfd_create, "prime-area", MFD_CLOEXEC);
                  ^

http://kisskb.ellerman.id.au/kisskb/buildresult/12473453/

We recently made some changes to skip other sample/test programs when cross compiling in mainline 65f6f092a6987 and f59514b6a8c5ca6dd and 6a407a81a9abcf. Maybe it makes sense to do the same here?

Paul.

David Herrmann

2015-07-29 16:31 UTC #1 lore raw

Quoted 7 lines · Paul Gortmaker

Hi David,
Does it make sense to build this sample when cross compiling?
The reason I ask is that it has been breaking the linux-next build of allmodconfig for a while now, with:

Quoted 8 lines

HOSTCC samples/kdbus/kdbus-workers
samples/kdbus/kdbus-workers.c: In function ‘prime_new’:
samples/kdbus/kdbus-workers.c:934:18: error: ‘__NR_memfd_create’ undeclared (first use in this function)
  p->fd = syscall(__NR_memfd_create, "prime-area", MFD_CLOEXEC);
                  ^
samples/kdbus/kdbus-workers.c:934:18: note: each undeclared identifier is reported only once for each function it appears in scripts/Makefile.host:91: recipe for target 'samples/kdbus/kdbus-workers' failed
make[2]: *** [samples/kdbus/kdbus-workers] Error 1

mips does have this syscall, so I assume the problem is out-of-date kernel headers. You can fix this by running:

    $ make headers_install

This will put the sanitized headers in your local kernel tree "./usr/". This is preferred over "/usr" as include path for the kernel examples, hence, everything should work fine then.

The kernel samples/ directory is explicitly used for example programs for the kernel. Hence, I think it is quite fine to use new kernel features. Same applies to the selftests.

I'd be fine making kdbus-workers a no-op program if __NR_memfd_create is not defined. But I'm not really sure that fixes real problems. I mean, new samples and selftests will be added by other subsystems and those might as well require new kernel headers.

Thanks
David

Michael Ellerman

2015-07-30 01:28 UTC #10 lore raw

In reply to Paul Gortmaker

Quoted 16 lines · Paul Gortmaker

Hi David,
Does it make sense to build this sample when cross compiling?
The reason I ask is that it has been breaking the linux-next build of allmodconfig for a while now, with:
HOSTCC samples/kdbus/kdbus-workers
samples/kdbus/kdbus-workers.c: In function ‘prime_new’:
samples/kdbus/kdbus-workers.c:934:18: error: ‘__NR_memfd_create’ undeclared (first use in this function)
  p->fd = syscall(__NR_memfd_create, "prime-area", MFD_CLOEXEC);
                  ^
samples/kdbus/kdbus-workers.c:934:18: note: each undeclared identifier is reported only once for each function it appears in scripts/Makefile.host:91: recipe for target 'samples/kdbus/kdbus-workers' failed
make[2]: *** [samples/kdbus/kdbus-workers] Error 1

Quoted 5 lines

http://kisskb.ellerman.id.au/kisskb/buildresult/12473453/
We recently made some changes to skip other sample/test programs when cross compiling in mainline 65f6f092a6987 and f59514b6a8c5ca6dd and 6a407a81a9abcf. Maybe it makes sense to do the same here?

Hi Paul,

We also can configure kisskb to not build samples for all_modconfig, which avoids these sort of issues with a slight decrease in code coverage. We already disable samples for several other arch all_modconfigs.

cheers

Paul Gortmaker

author

2015-07-30 13:50 UTC #2 lore raw

In reply to David Herrmann

Quoted 20 lines · David Herrmann

Hi
Quoted 7 lines · Paul Gortmaker
Hi David,
Does it make sense to build this sample when cross compiling?
The reason I ask is that it has been breaking the linux-next build of allmodconfig for a while now, with:
Quoted 8 lines
HOSTCC samples/kdbus/kdbus-workers
samples/kdbus/kdbus-workers.c: In function ‘prime_new’:
samples/kdbus/kdbus-workers.c:934:18: error: ‘__NR_memfd_create’ undeclared (first use in this function)
  p->fd = syscall(__NR_memfd_create, "prime-area", MFD_CLOEXEC);
                  ^
samples/kdbus/kdbus-workers.c:934:18: note: each undeclared identifier is reported only once for each function it appears in scripts/Makefile.host:91: recipe for target 'samples/kdbus/kdbus-workers' failed
make[2]: *** [samples/kdbus/kdbus-workers] Error 1

Quoted 4 lines

mips does have this syscall, so I assume the problem is out-of-date kernel headers. You can fix this by running:
    $ make headers_install

No, let me try and clarify. Please note the emphasis on cross compiling and automated build coverage, i.e. there is no place for manual steps.

On kernel.org there are x86 host binaries that allow a person to build a kernel for nearly every arch:

https://www.kernel.org/pub/tools/crosstool/

These exist so developers doing treewide changes can test that their work does not break s390 or powerpc, or ....

However, in the interest of simplicity, these compilers are created such that they can build the self contained kernel only. They do not have all the headers and libc stuff needed to compile and link an actual s390 or powerpc userspace -- for that you'd need a full sysroot.

And this is fine for 99.9% of stuff. And it was fine for the automated
builds of the linux-next tree for the MIPS architecture and the allmodconfig target prior to the kdbus inclusion.

And I really don't need a s390 or powerpc sample program, hence why I suggested we skip it when cross compiling, just like the other commits I quoted.

The implicit rule with linux-next (and linux in general) is essentially
"You broke it, you get to fix it." So either skipping this in the
Makefile when cross compiling, or working with Michael and the linux-next team to have their builders somehow skip it needs to be done by the kdbus team.

Thanks,
Paul.
--

Quoted 17 lines

This will put the sanitized headers in your local kernel tree "./usr/". This is preferred over "/usr" as include path for the kernel examples, hence, everything should work fine then.
The kernel samples/ directory is explicitly used for example programs for the kernel. Hence, I think it is quite fine to use new kernel features. Same applies to the selftests.
I'd be fine making kdbus-workers a no-op program if __NR_memfd_create is not defined. But I'm not really sure that fixes real problems. I mean, new samples and selftests will be added by other subsystems and those might as well require new kernel headers.
Thanks
David

David Herrmann

2015-07-30 14:23 UTC #3 lore raw

Quoted 21 lines · Paul Gortmaker

Quoted 20 lines · David Herrmann
Hi
Quoted 15 lines · Paul Gortmaker
Hi David,
Does it make sense to build this sample when cross compiling?
The reason I ask is that it has been breaking the linux-next build of allmodconfig for a while now, with:
HOSTCC samples/kdbus/kdbus-workers
samples/kdbus/kdbus-workers.c: In function ‘prime_new’:
samples/kdbus/kdbus-workers.c:934:18: error: ‘__NR_memfd_create’ undeclared (first use in this function)
  p->fd = syscall(__NR_memfd_create, "prime-area", MFD_CLOEXEC);
                  ^
samples/kdbus/kdbus-workers.c:934:18: note: each undeclared identifier is reported only once for each function it appears in scripts/Makefile.host:91: recipe for target 'samples/kdbus/kdbus-workers' failed
make[2]: *** [samples/kdbus/kdbus-workers] Error 1

Quoted 7 lines

Quoted 4 lines
mips does have this syscall, so I assume the problem is out-of-date kernel headers. You can fix this by running:
    $ make headers_install
No, let me try and clarify. Please note the emphasis on cross compiling and automated build coverage, i.e. there is no place for manual steps.

User-space samples in ./samples/ are compiled with HOSTCC, which is the compiler for the _local_ machine. Regardless of cross-compiling the same local compiler is used. So I cannot understand why this is even remotely related to cross compiling. Please elaborate. Please note that this is HOSTCC running, so it does *NOT* require the toolchain for your cross-compiled architecture.

Also, please tell me why your system has "linux/memfd.h" available, but __NR_memfd_create is undefined?

Anyway, patch is attached. Can you verify it works? David

samples/kdbus/Makefile +4 -0

index 137f842..dbd9de8 100644
@@ -1,9 +1,13 @@
 # kbuild trick to avoid linker error. Can be omitted if a module is built.
 obj- := dummy.o
 
+ifndef CROSS_COMPILE
+
 hostprogs-$(CONFIG_SAMPLE_KDBUS) += kdbus-workers
 
 always := $(hostprogs-y)
 
 HOSTCFLAGS_kdbus-workers.o += -I$(objtree)/usr/include
 HOSTLOADLIBES_kdbus-workers := -lrt
+
+endif

Paul Gortmaker

author Tested-by

2015-07-30 15:32 UTC #4 lore raw

Quoted 30 lines · David Herrmann

Hi
Quoted 26 lines · Paul Gortmaker
Quoted 24 lines · David Herrmann
Hi
Quoted 7 lines · Paul Gortmaker
Hi David,
Does it make sense to build this sample when cross compiling?
The reason I ask is that it has been breaking the linux-next build of allmodconfig for a while now, with:
Quoted 8 lines
HOSTCC samples/kdbus/kdbus-workers
samples/kdbus/kdbus-workers.c: In function ‘prime_new’:
samples/kdbus/kdbus-workers.c:934:18: error: ‘__NR_memfd_create’ undeclared (first use in this function)
  p->fd = syscall(__NR_memfd_create, "prime-area", MFD_CLOEXEC);
                  ^
samples/kdbus/kdbus-workers.c:934:18: note: each undeclared identifier is reported only once for each function it appears in scripts/Makefile.host:91: recipe for target 'samples/kdbus/kdbus-workers' failed
make[2]: *** [samples/kdbus/kdbus-workers] Error 1
mips does have this syscall, so I assume the problem is out-of-date kernel headers. You can fix this by running:
    $ make headers_install

Quoted 7 lines

Quoted 2 lines
No, let me try and clarify. Please note the emphasis on cross compiling and automated build coverage, i.e. there is no place for manual steps.
User-space samples in ./samples/ are compiled with HOSTCC, which is the compiler for the _local_ machine. Regardless of cross-compiling the same local compiler is used. So I cannot understand why this is even remotely related to cross compiling. Please elaborate.

Well, it only shows up when we cross compile for mips. It does not seem to be showing up for any other arch (and we cover ~10 of them). Nor does it show up for x86 builds. Also note that the main linux-next build machine is actually a PowerPC host.

Quoted 5 lines

Please note that this is HOSTCC running, so it does *NOT* require the toolchain for your cross-compiled architecture.
Also, please tell me why your system has "linux/memfd.h" available, but __NR_memfd_create is undefined?

My local system is a bog standard ubuntu 14.10 and it sees it. I dont know what distro the linux-next IBM powerpc builder is based on but it also sees it....

Here is what V=1 output looks like:

(cat /dev/null; ) > samples/kdbus/modules.order
gcc -Wp,-MD,samples/kdbus/.kdbus-workers.d -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu89 -I./usr/include -o samples/kdbus/kdbus-workers samples/kdbus/kdbus-workers.c -lrt
samples/kdbus/kdbus-workers.c: In function ‘prime_new’:
samples/kdbus/kdbus-workers.c:934:18: error: ‘__NR_memfd_create’ undeclared (first use in this function)

  p->fd = syscall(__NR_memfd_create, "prime-area", MFD_CLOEXEC);
                  ^

samples/kdbus/kdbus-workers.c:934:18: note: each undeclared identifier is reported only once for each function it appears in scripts/Makefile.host:91: recipe for target 'samples/kdbus/kdbus-workers' failed
make[2]: *** [samples/kdbus/kdbus-workers] Error 1
scripts/Makefile.build:403: recipe for target 'samples/kdbus' failed
make[1]: *** [samples/kdbus] Error 2
Makefile:1569: recipe for target 'samples/' failed
make: *** [samples/] Error 2

and here is what is in ./usr/include:

paul@yow-lpgnfs-02:~/git/linux-head$ grep -R __NR_memfd_create ./usr/include/
./usr/include/asm-generic/unistd.h:#define __NR_memfd_create 279
./usr/include/asm-generic/unistd.h:__SYSCALL(__NR_memfd_create, sys_memfd_create)
./usr/include/asm/unistd.h:#define __NR_memfd_create            (__NR_Linux + 354)
./usr/include/asm/unistd.h:#define __NR_memfd_create            (__NR_Linux + 314)
./usr/include/asm/unistd.h:#define __NR_memfd_create            (__NR_Linux + 318)
paul@yow-lpgnfs-02:~/git/linux-head$

..so it is in there, but presumably something wrt mips ifdeffery means it is thrown out by cpp.

Quoted 2 lines

Anyway, patch is attached. Can you verify it works?

Yes, after I fixed up the mangling from it being sent as quoted-printable, it fixes the issue; or at least avoids it.

Tested-by Paul Gortmaker <[email protected]>

Thanks,
Paul.
--

Quoted 21 lines

David

samples/kdbus/Makefile +4 -0

index 137f842..dbd9de8 100644
@@ -1,9 +1,13 @@
 # kbuild trick to avoid linker error. Can be omitted if a module is built.
 obj- := dummy.o
 
+ifndef CROSS_COMPILE
+
 hostprogs-$(CONFIG_SAMPLE_KDBUS) += kdbus-workers
 
 always := $(hostprogs-y)
 
 HOSTCFLAGS_kdbus-workers.o += -I$(objtree)/usr/include
 HOSTLOADLIBES_kdbus-workers := -lrt
+
+endif

Stephen Rothwell

2015-07-30 23:55 UTC #5 lore raw

Hi Paul,

Quoted 5 lines · On Thu, 30 Jul 2015 11:32:05 -0400 Paul Gortmaker…

Well, it only shows up when we cross compile for mips. It does not seem to be showing up for any other arch (and we cover ~10 of them). Nor does it show up for x86 builds. Also note that the main linux-next build machine is actually a PowerPC host.

Actually I do my linux-next builds on an x86_64 host, and the overnight builds are spread between that and a PowerPC host.

Quoted 9 lines

Quoted 5 lines
Please note that this is HOSTCC running, so it does *NOT* require the toolchain for your cross-compiled architecture.
Also, please tell me why your system has "linux/memfd.h" available, but __NR_memfd_create is undefined?
My local system is a bog standard ubuntu 14.10 and it sees it. I dont know what distro the linux-next IBM powerpc builder is based on but it also sees it....

Our build hosts are running Debian stable and Ubuntu <mumble> (I think - I will check on this latter).

Signature · 2 lines

Cheers,
Stephen Rothwell                    [email protected]

Michael Ellerman

2015-07-31 06:54 UTC #6 lore raw

Quoted 18 lines · Stephen Rothwell

Hi Paul,
Quoted 5 lines · On Thu, 30 Jul 2015 11:32:05 -0400 Paul Gortmaker…
Well, it only shows up when we cross compile for mips. It does not seem to be showing up for any other arch (and we cover ~10 of them). Nor does it show up for x86 builds. Also note that the main linux-next build machine is actually a PowerPC host.
Actually I do my linux-next builds on an x86_64 host, and the overnight builds are spread between that and a PowerPC host.
Quoted 6 lines
Quoted 5 lines
Please note that this is HOSTCC running, so it does *NOT* require the toolchain for your cross-compiled architecture.
Also, please tell me why your system has "linux/memfd.h" available, but __NR_memfd_create is undefined?

Quoted 6 lines

Quoted 3 lines
My local system is a bog standard ubuntu 14.10 and it sees it. I dont know what distro the linux-next IBM powerpc builder is based on but it also sees it....
Our build hosts are running Debian stable and Ubuntu <mumble> (I think - I will check on this latter).

The x86 builders are debian:jessie and the ppc one is currently Ubuntu 14.04.2.

cheers

Michael Ellerman

2015-07-31 07:01 UTC #7 lore raw

In reply to David Herrmann

Quoted 33 lines · David Herrmann

Hi
Quoted 21 lines · Paul Gortmaker
Quoted 20 lines · David Herrmann
Hi
Quoted 15 lines · Paul Gortmaker
Hi David,
Does it make sense to build this sample when cross compiling?
The reason I ask is that it has been breaking the linux-next build of allmodconfig for a while now, with:
HOSTCC samples/kdbus/kdbus-workers
samples/kdbus/kdbus-workers.c: In function ‘prime_new’:
samples/kdbus/kdbus-workers.c:934:18: error: ‘__NR_memfd_create’ undeclared (first use in this function)
  p->fd = syscall(__NR_memfd_create, "prime-area", MFD_CLOEXEC);
                  ^
samples/kdbus/kdbus-workers.c:934:18: note: each undeclared identifier is reported only once for each function it appears in scripts/Makefile.host:91: recipe for target 'samples/kdbus/kdbus-workers' failed
make[2]: *** [samples/kdbus/kdbus-workers] Error 1
Quoted 7 lines
Quoted 4 lines
mips does have this syscall, so I assume the problem is out-of-date kernel headers. You can fix this by running:
    $ make headers_install
No, let me try and clarify. Please note the emphasis on cross compiling and automated build coverage, i.e. there is no place for manual steps.

Quoted 6 lines

User-space samples in ./samples/ are compiled with HOSTCC, which is the compiler for the _local_ machine. Regardless of cross-compiling the same local compiler is used. So I cannot understand why this is even remotely related to cross compiling. Please elaborate. Please note that this is HOSTCC running, so it does *NOT* require the toolchain for your cross-compiled architecture.

Right. Our cross toolchain wouldn't build it anyway, as it has no libc.

Quoted 2 lines

Also, please tell me why your system has "linux/memfd.h" available, but __NR_memfd_create is undefined?

Because it's building with the HOSTCC (x86_64), against the MIPS kernel headers. And the MIPS kernel headers are structured in such a way that on a non-mips build they don't define the syscall numbers.

The reason we have the MIPS headers installed is because CONFIG_HEADERS_CHECK is turned on (because allmodconfig).

So that just basically makes no sense to me.

It's obviously possible that some samples build with that configuration, but building against another arch'es kernel headers just seems like it's asking for trouble. Even if we can build the samples, they will never run correctly.

So I suggest we should just disable SAMPLES if we're cross compiling, full stop.

cheers

Greg Kroah-Hartman

2015-07-31 16:29 UTC #8 lore raw

Quoted 5 lines · Michael Ellerman

It's obviously possible that some samples build with that configuration, but building against another arch'es kernel headers just seems like it's asking for trouble. Even if we can build the samples, they will never run correctly.
So I suggest we should just disable SAMPLES if we're cross compiling, full stop.

Yes, that seems like a much better solution overall. Can you send a patch for this?

thanks,

greg k-h

Michael Ellerman

2015-08-03 04:58 UTC #9 lore raw

Quoted 9 lines · Greg Kroah-Hartman

Quoted 5 lines · Michael Ellerman
It's obviously possible that some samples build with that configuration, but building against another arch'es kernel headers just seems like it's asking for trouble. Even if we can build the samples, they will never run correctly.
So I suggest we should just disable SAMPLES if we're cross compiling, full stop.
Yes, that seems like a much better solution overall. Can you send a patch for this?

Yep, will do.

cheers