From: Masahiro Yamada <masahiroy@kernel.org>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Michal Marek <michal.lkml@markovi.net>,
Sam Ravnborg <sam@ravnborg.org>,
clang-built-linux <clang-built-linux@googlegroups.com>
Subject: Re: [PATCH] kbuild: make Clang build userprogs for target architecture
Date: Wed, 1 Jul 2020 01:23:53 +0900 [thread overview]
Message-ID: <CAK7LNAR49jFZkEmBqpACE0V_-VyCXfFRcKe1Zq+cqO65QX1ozg@mail.gmail.com> (raw)
In-Reply-To: <CAKwvOd=qe5KE1vdUYQmpsW2zmDbk5i-MgRujs9B7wqnAj+af0w@mail.gmail.com>
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
--
Best Regards
Masahiro Yamada
next prev parent reply other threads:[~2020-06-30 16:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-29 8:59 [PATCH] kbuild: make Clang build userprogs for target architecture Masahiro Yamada
2020-06-29 17:38 ` Nick Desaulniers
2020-06-30 16:23 ` Masahiro Yamada [this message]
2020-06-30 19:12 ` Miguel Ojeda
2020-07-05 15:29 ` Masahiro Yamada
2020-07-06 4:48 ` Miguel Ojeda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAK7LNAR49jFZkEmBqpACE0V_-VyCXfFRcKe1Zq+cqO65QX1ozg@mail.gmail.com \
--to=masahiroy@kernel.org \
--cc=clang-built-linux@googlegroups.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.lkml@markovi.net \
--cc=ndesaulniers@google.com \
--cc=sam@ravnborg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.