kbuild: make Clang build userprogs for target architecture
diff mbox series

Message ID 20200629085911.1676554-1-masahiroy@kernel.org
State New
Headers show
Series
  • kbuild: make Clang build userprogs for target architecture
Related show

Commit Message

Masahiro Yamada June 29, 2020, 8:59 a.m. UTC
Programs added 'userprogs' should be compiled for the target
architecture i.e. the same architecture as the kernel.

GCC does this correctly since the target architecture is implied
by the toolchain prefix.

Clang builds standalone programs always for the host architecture
because the target triple is currently missing.

Fix this.

Fixes: 7f3a59db274c ("kbuild: add infrastructure to build userspace programs")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
---

 Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Nick Desaulniers June 29, 2020, 5:38 p.m. UTC | #1
On Mon, Jun 29, 2020 at 1:59 AM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> Programs added 'userprogs' should be compiled for the target
> architecture i.e. the same architecture as the kernel.
>
> GCC does this correctly since the target architecture is implied
> by the toolchain prefix.
>
> Clang builds standalone programs always for the host architecture
> because the target triple is currently missing.
>
> Fix this.
>
> Fixes: 7f3a59db274c ("kbuild: add infrastructure to build userspace programs")

This is a neat feature I didn't know about; looks relatively new.
What's the test case command line invocation to test this with Clang?

> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> ---
>
>  Makefile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 73948798ce3f..cac29cc2ec25 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -970,8 +970,8 @@ LDFLAGS_vmlinux     += --pack-dyn-relocs=relr
>  endif
>
>  # Align the bit size of userspace programs with the kernel
> -KBUILD_USERCFLAGS  += $(filter -m32 -m64, $(KBUILD_CFLAGS))
> -KBUILD_USERLDFLAGS += $(filter -m32 -m64, $(KBUILD_CFLAGS))
> +KBUILD_USERCFLAGS  += $(filter -m32 -m64 --target=%, $(KBUILD_CFLAGS))
> +KBUILD_USERLDFLAGS += $(filter -m32 -m64 --target=%, $(KBUILD_CFLAGS))

That should be fine.
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
https://www.gnu.org/software/make/manual/html_node/Text-Functions.html

>
>  # make the checker run with the right architecture
>  CHECKFLAGS += --arch=$(ARCH)
> --
Masahiro Yamada June 30, 2020, 4:23 p.m. UTC | #2
On Tue, Jun 30, 2020 at 2:39 AM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> On Mon, Jun 29, 2020 at 1:59 AM Masahiro Yamada <masahiroy@kernel.org> wrote:
> >
> > Programs added 'userprogs' should be compiled for the target
> > architecture i.e. the same architecture as the kernel.
> >
> > GCC does this correctly since the target architecture is implied
> > by the toolchain prefix.
> >
> > Clang builds standalone programs always for the host architecture
> > because the target triple is currently missing.
> >
> > Fix this.
> >
> > Fixes: 7f3a59db274c ("kbuild: add infrastructure to build userspace programs")
>
> This is a neat feature I didn't know about; looks relatively new.
> What's the test case command line invocation to test this with Clang?



Test command:

$ make -j24 ARCH=arm  LLVM=1 CROSS_COMPILE=arm-linux-gnueabi-
allyesconfig  samples/
  [ snip ]
  CC [U]  samples/watch_queue/watch_test
  CC [U]  samples/timers/hpet_example
  CC [U]  samples/vfs/test-fsmount
  CC [U]  samples/binderfs/binderfs_example
  CC [U]  samples/auxdisplay/cfag12864b-example
  CC [U]  samples/hidraw/hid-example
  CC [U]  samples/uhid/uhid-example
  CC [U]  samples/connector/ucon
  CC [U]  samples/watchdog/watchdog-simple
  CC [U]  samples/vfs/test-statx


Then, check if the sample programs
were correctly built for ARM.



Before this commit:

$ file samples/vfs/test-statx
samples/vfs/test-statx: ELF 64-bit LSB executable, x86-64, version 1
(SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
for GNU/Linux 3.2.0, not stripped



After this commit:

$ file samples/vfs/test-statx
samples/vfs/test-statx: ELF 32-bit LSB executable, ARM, EABI5 version
1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for
GNU/Linux 3.2.0, not stripped



To test this, having LLVM is not enough
because building userspace programs
requires target-specific libraries.

As for GCC, libc is usually bundled together
with toolchains, but as for LLVM we need
to provide target-specific libc.

This introduces a different kind of complexity
than building the kernel.

I read this article:
https://clang.llvm.org/docs/CrossCompilation.html


I use tc-build to compile llvm from source code,
but I also needed to install ARM libc.

"apt install gcc-arm-linux-gnueabi"
especially
"apt install libc6-dev-armel-cross".





If I build sample code for ARCH=arm64,
I see the following warnings.


$ make -j24 ARCH=arm64  LLVM=1 CROSS_COMPILE=aarch64-linux-gnu-
allyesconfig  samples/
  [ snip ]
  CC [U]  samples/uhid/uhid-example
samples/uhid/uhid-example.c:169:4: warning: format specifies type
'ssize_t' (aka 'long') but the argument has type 'ssize_t' (aka 'int')
[-Wformat]
                        ret, sizeof(ev));
                        ^~~
samples/uhid/uhid-example.c:240:4: warning: format specifies type
'ssize_t' (aka 'long') but the argument has type 'ssize_t' (aka 'int')
[-Wformat]
                        ret, sizeof(ev));
                        ^~~
2 warnings generated.
  CC [U]  samples/vfs/test-fsmount
  CC [U]  samples/vfs/test-statx
  CC [U]  samples/watch_queue/watch_test
samples/watch_queue/watch_test.c:86:50: warning: format specifies type
'ssize_t' (aka 'long') but the argument has type 'ssize_t' (aka 'int')
[-Wformat]
                        fprintf(stderr, "Read buffer overrun: %zd\n", buf_len);
                                                              ~~~     ^~~~~~~
                                                              %d
samples/watch_queue/watch_test.c:90:28: warning: format specifies type
'ssize_t' (aka 'long') but the argument has type 'ssize_t' (aka 'int')
[-Wformat]
                printf("read() = %zd\n", buf_len);
                                 ~~~     ^~~~~~~
                                 %d
2 warnings generated.
  CC [U]  samples/watchdog/watchdog-simple
  AR      samples/built-in.a





I do not know how to solve this issue.


I can reproduce this in the following
simple test code:


----------------->8----------------
#include <stdio.h>

int main(void)
{
        ssize_t x = 1;

        printf("%zd", x);

        return 0;
}
--------------->8-------------------

$ clang --target=aarch64-linux-gnu test.c
test.c:7:16: warning: format specifies type 'ssize_t' (aka 'long') but
the argument has type 'ssize_t' (aka 'int') [-Wformat]
        printf("%zd", x);
                ~~~   ^
                %zd
1 warning generated.


ssize_t is defined in /usr/include/stdio.h
but perhaps this is not suitable
for cross-compilation for aarch64.



Is there any solution?






> > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> > ---
> >
> >  Makefile | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 73948798ce3f..cac29cc2ec25 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -970,8 +970,8 @@ LDFLAGS_vmlinux     += --pack-dyn-relocs=relr
> >  endif
> >
> >  # Align the bit size of userspace programs with the kernel
> > -KBUILD_USERCFLAGS  += $(filter -m32 -m64, $(KBUILD_CFLAGS))
> > -KBUILD_USERLDFLAGS += $(filter -m32 -m64, $(KBUILD_CFLAGS))
> > +KBUILD_USERCFLAGS  += $(filter -m32 -m64 --target=%, $(KBUILD_CFLAGS))
> > +KBUILD_USERLDFLAGS += $(filter -m32 -m64 --target=%, $(KBUILD_CFLAGS))
>
> That should be fine.
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> https://www.gnu.org/software/make/manual/html_node/Text-Functions.html
>
> >
> >  # make the checker run with the right architecture
> >  CHECKFLAGS += --arch=$(ARCH)
> > --
>
>
> --
> Thanks,
> ~Nick Desaulniers
Miguel Ojeda June 30, 2020, 7:12 p.m. UTC | #3
On Tue, Jun 30, 2020 at 6:26 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> I can reproduce this in the following
> simple test code:
>
>
> ----------------->8----------------
> #include <stdio.h>
>
> int main(void)
> {
>         ssize_t x = 1;
>
>         printf("%zd", x);
>
>         return 0;
> }
> --------------->8-------------------

That is the old implicit int rule. Try including sys/types.h or
compiling with a standard like -std=c99 for instance.

Cheers,
Miguel
Masahiro Yamada July 5, 2020, 3:29 p.m. UTC | #4
On Wed, Jul 1, 2020 at 4:13 AM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Tue, Jun 30, 2020 at 6:26 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
> >
> > I can reproduce this in the following
> > simple test code:
> >
> >
> > ----------------->8----------------
> > #include <stdio.h>
> >
> > int main(void)
> > {
> >         ssize_t x = 1;
> >
> >         printf("%zd", x);
> >
> >         return 0;
> > }
> > --------------->8-------------------
>
> That is the old implicit int rule. Try including sys/types.h or
> compiling with a standard like -std=c99 for instance.
>
> Cheers,
> Miguel

Hmm, adding '#include <sys/types.h>' did not make any difference.




If I add -std=c99, I get a different error.


$ clang -std=c99 --target=aarch64-linux-gnu test.c
test.c:5:10: error: unknown type name 'ssize_t'; did you mean 'size_t'?
         ssize_t x = 1;
         ^~~~~~~
         size_t
/home/masahiro/tools/clang-latest/lib/clang/11.0.0/include/stddef.h:46:23:
note: 'size_t' declared here
typedef __SIZE_TYPE__ size_t;
                      ^
1 error generated.





In contrast, 'size_t' has no problem.


----------------->8----------------
#include <stdio.h>

int main(void)
{
         size_t x = 1;

         printf("%zu", x);

         return 0;
}
--------------->8-------------------

$ clang  --target=aarch64-linux-gnu test.c
[ No warning ]




--
Best Regards
Masahiro Yamada
Miguel Ojeda July 6, 2020, 4:48 a.m. UTC | #5
Hi Masahiro,

On Sun, Jul 5, 2020 at 5:30 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> Hmm, adding '#include <sys/types.h>' did not make any difference.

That should have worked, because POSIX defines it to be there. It
sounds like you need --sysroot to point it to the proper ones.

> If I add -std=c99, I get a different error.

Yeah, that is the expected behavior. C99 does not have the implicit
int rule anymore (unlike older C) so ssize_t (an unknown type given
that program) is not being interpreted as int anymore (which is what
triggers the warning later about the mismatch between size_t and int
in the format string).

> In contrast, 'size_t' has no problem.

That is expected too, because size_t is defined via stdio.h (size_t is
a C standard type, ssize_t is not -- it is a POSIX one).

Hope that helps,

Cheers,
Miguel

Patch
diff mbox series

diff --git a/Makefile b/Makefile
index 73948798ce3f..cac29cc2ec25 100644
--- a/Makefile
+++ b/Makefile
@@ -970,8 +970,8 @@  LDFLAGS_vmlinux	+= --pack-dyn-relocs=relr
 endif
 
 # Align the bit size of userspace programs with the kernel
-KBUILD_USERCFLAGS  += $(filter -m32 -m64, $(KBUILD_CFLAGS))
-KBUILD_USERLDFLAGS += $(filter -m32 -m64, $(KBUILD_CFLAGS))
+KBUILD_USERCFLAGS  += $(filter -m32 -m64 --target=%, $(KBUILD_CFLAGS))
+KBUILD_USERLDFLAGS += $(filter -m32 -m64 --target=%, $(KBUILD_CFLAGS))
 
 # make the checker run with the right architecture
 CHECKFLAGS += --arch=$(ARCH)