All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.