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

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

[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

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.

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

[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

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.

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

[David Herrmann]

Hi

On Wed, Jul 29, 2015 at 6:19 PM, Paul Gortmaker
<paul.gortmaker@windriver.com> wrote:
> 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

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

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

[Michael Ellerman]

On Wed, 2015-07-29 at 12:19 -0400, Paul Gortmaker wrote:
> 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
> 
> 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

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

[Paul Gortmaker]

On 2015-07-29 12:31 PM, David Herrmann wrote:
> Hi
> 
> On Wed, Jul 29, 2015 at 6:19 PM, Paul Gortmaker
> <paul.gortmaker@windriver.com> wrote:
>> 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
> 
> 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.
--

> 
> 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
> 

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

[Paul Gortmaker]

On 2015-07-29 12:31 PM, David Herrmann wrote:
> Hi
> 
> On Wed, Jul 29, 2015 at 6:19 PM, Paul Gortmaker
> <paul.gortmaker@windriver.com> wrote:
>> 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
> 
> 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.
--

> 
> 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
> 

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

[David Herrmann]

Hi

On Thu, Jul 30, 2015 at 3:50 PM, Paul Gortmaker
<paul.gortmaker@windriver.com> wrote:
> On 2015-07-29 12:31 PM, David Herrmann wrote:
>> Hi
>>
>> On Wed, Jul 29, 2015 at 6:19 PM, Paul Gortmaker
>> <paul.gortmaker@windriver.com> wrote:
>>> 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
>>
>> 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

diff --git a/samples/kdbus/Makefile b/samples/kdbus/Makefile
index 137f842..dbd9de8 100644
--- a/samples/kdbus/Makefile
+++ b/samples/kdbus/Makefile
@@ -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

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

[Paul Gortmaker]

On 2015-07-30 10:23 AM, David Herrmann wrote:
> Hi
> 
> On Thu, Jul 30, 2015 at 3:50 PM, Paul Gortmaker
> <paul.gortmaker@windriver.com> wrote:
>> On 2015-07-29 12:31 PM, David Herrmann wrote:
>>> Hi
>>>
>>> On Wed, Jul 29, 2015 at 6:19 PM, Paul Gortmaker
>>> <paul.gortmaker@windriver.com> wrote:
>>>> 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
>>>
>>> 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.

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.

> 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.

> 
> 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 <paul.gortmaker@windriver.com>

Thanks,
Paul.
--

> David
> 
> diff --git a/samples/kdbus/Makefile b/samples/kdbus/Makefile
> index 137f842..dbd9de8 100644
> --- a/samples/kdbus/Makefile
> +++ b/samples/kdbus/Makefile
> @@ -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
> 

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

[Paul Gortmaker]

On 2015-07-30 10:23 AM, David Herrmann wrote:
> Hi
> 
> On Thu, Jul 30, 2015 at 3:50 PM, Paul Gortmaker
> <paul.gortmaker@windriver.com> wrote:
>> On 2015-07-29 12:31 PM, David Herrmann wrote:
>>> Hi
>>>
>>> On Wed, Jul 29, 2015 at 6:19 PM, Paul Gortmaker
>>> <paul.gortmaker@windriver.com> wrote:
>>>> 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
>>>
>>> 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.

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.

> 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.

> 
> 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 <paul.gortmaker@windriver.com>

Thanks,
Paul.
--

> David
> 
> diff --git a/samples/kdbus/Makefile b/samples/kdbus/Makefile
> index 137f842..dbd9de8 100644
> --- a/samples/kdbus/Makefile
> +++ b/samples/kdbus/Makefile
> @@ -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
> 

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

[Stephen Rothwell]

Hi Paul,

On Thu, 30 Jul 2015 11:32:05 -0400 Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
>
> 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.

> > 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).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

[Stephen Rothwell]

Hi Paul,

On Thu, 30 Jul 2015 11:32:05 -0400 Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
>
> 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.

> > 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).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

[Michael Ellerman]

On Fri, 2015-07-31 at 09:55 +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> On Thu, 30 Jul 2015 11:32:05 -0400 Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
> >
> > 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.
> 
> > > 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).

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

cheers

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

[Michael Ellerman]

On Thu, 2015-07-30 at 16:23 +0200, David Herrmann wrote:
> Hi
> 
> On Thu, Jul 30, 2015 at 3:50 PM, Paul Gortmaker
> <paul.gortmaker@windriver.com> wrote:
> > On 2015-07-29 12:31 PM, David Herrmann wrote:
> >> Hi
> >>
> >> On Wed, Jul 29, 2015 at 6:19 PM, Paul Gortmaker
> >> <paul.gortmaker@windriver.com> wrote:
> >>> 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
> >>
> >> 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.

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

> 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

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

[Greg Kroah-Hartman]

On Fri, Jul 31, 2015 at 05:01:01PM +1000, Michael Ellerman wrote:
> 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

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

[Michael Ellerman]

On Fri, 2015-07-31 at 09:29 -0700, Greg Kroah-Hartman wrote:
> On Fri, Jul 31, 2015 at 05:01:01PM +1000, Michael Ellerman wrote:
> > 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