ARCH=hexagon unsupported?

[Nick Desaulniers]

Arnd,
No one can build ARCH=hexagon and
https://github.com/ClangBuiltLinux/linux/issues/759 has been open for
2 years.

Trying to build
$ ARCH=hexagon CROSS_COMPILE=hexagon-linux-gnu make LLVM=1 LLVM_IAS=1 -j71

shows numerous issues, the latest of which
commit 8320514c91bea ("hexagon: switch to ->regset_get()")
has a very obvious typo which misspells the `struct` keyword and has
been in the tree for almost 1 year.

Why is arch/hexagon/ in the tree if no one can build it?
--
Thanks,
~Nick Desaulniers

[Arnd Bergmann]

On Fri, Apr 23, 2021 at 12:12 AM 'Nick Desaulniers' via Clang Built
Linux <clang-bu...@googlegroups.com> wrote:
>
> Arnd,
> No one can build ARCH=hexagon and
> https://github.com/ClangBuiltLinux/linux/issues/759 has been open for
> 2 years.
>
> Trying to build
> $ ARCH=hexagon CROSS_COMPILE=hexagon-linux-gnu make LLVM=1 LLVM_IAS=1 -j71
>
> shows numerous issues, the latest of which
> commit 8320514c91bea ("hexagon: switch to ->regset_get()")
> has a very obvious typo which misspells the `struct` keyword and has
> been in the tree for almost 1 year.

Thank you for looking into it.

> Why is arch/hexagon/ in the tree if no one can build it?

Removing it sounds reasonable to me, it's been broken for too long, and
we did the same thing for unicore32 that was in the same situation
where the gcc port was too old to build the kernel and the clang
port never quite work in mainline.

Guenter also brought up the issue a year ago, and nothing happened.
I see Brian still occasionally sends an Ack to a patch that gets merged
through another tree, but he has not send any patches or pull requests
himself after taking over maintainership from Richard Kuo in 2019,
and the four hexagon pull requests after 2014 only contained build fixes
from developers that don't have access to the hardware (Randy Dunlap,
Viresh Kumar, Mike Frysinger and me).

Arnd

[1] https://lore.kernel.org/lkml/04ca01d633a8$9abb8070$d0328150$@codeaurora.org/

---
$ git log --grep=linux-hexagon-kernel
commit bb736a5c0e9a2605f11c2bbb60a68f757832da32
Merge: 45979a956b92 18dd1793a340
Author: Linus Torvalds <torv...@linux-foundation.org>
Date: Fri Sep 20 11:28:43 2019 -0700

Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/rkuo/linux-hexagon-kernel

Pull Hexagon maintainership update from Richard Kuo:
"I am leaving QuIC, and Brian Cain will be taking over maintainership
of the Hexagon port"

* 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/rkuo/linux-hexagon-kernel:
Hexagon: change maintainer to Brian Cain

commit 72d4c6e5893a122c2fd060ded2b490582a5bb377
Merge: 1d176582c795 5c41aaad409c
Author: Linus Torvalds <torv...@linux-foundation.org>
Date: Thu Sep 13 16:33:26 2018 -1000

Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/rkuo/linux-hexagon-kernel

Pull hexagon fixes from Richard Kuo:
"Some fixes for compile warnings"

* 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/rkuo/linux-hexagon-kernel:
hexagon: modify ffs() and fls() to return int
arch/hexagon: fix kernel/dma.c build warning

commit 2d618bdf71635463a4aa4ad0fe46ec852292bc0c
Merge: f2125992e7cb 330e261c35df
Author: Linus Torvalds <torv...@linux-foundation.org>
Date: Tue May 1 19:54:22 2018 -0700

Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/rkuo/linux-hexagon-kernel

Pull hexagon fixes from Richard Kuo:
"Some small fixes for module compilation"

* 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/rkuo/linux-hexagon-kernel:
hexagon: export csum_partial_copy_nocheck
hexagon: add memset_io() helper

commit 0cdf5a464070c8a2980a27113c47fb8e71babb9c
Merge: 65c61bc5dbbc 02cc2ccfe771
Author: Linus Torvalds <torv...@linux-foundation.org>
Date: Thu Sep 10 16:19:07 2015 -0700

Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/rkuo/linux-hexagon-kernel

Pull hexagon updates from Richard Kuo:
"Just two fixes -- one for a uapi header and one for a timer interface"

* 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/rkuo/linux-hexagon-kernel:
Revert "Hexagon: fix signal.c compile error"
hexagon/time: Migrate to new 'set-state' interface

[Randy Dunlap]

There is no current gcc C compiler in the 3 locations that I know of to look.
The one I tried is v4.6 and it is too old to work with current makefiles.

--
~Randy

[Arnd Bergmann]

Correct, as I understand it , work on gcc was stopped after the 4.6 release and
any testing internally to Qualcomm was done using a patched clang. A few years
ago this was said to be (almost?) entirely upstream, but as Nick points out
it has never been possible to build an upstream hexagon kernel with an upstream
clang.

Arnd

[Miguel Ojeda]

On Fri, Apr 23, 2021 at 8:18 PM Arnd Bergmann <ar...@kernel.org> wrote:
>
> Correct, as I understand it , work on gcc was stopped after the 4.6 release and
> any testing internally to Qualcomm was done using a patched clang. A few years
> ago this was said to be (almost?) entirely upstream, but as Nick points out
> it has never been possible to build an upstream hexagon kernel with an upstream
> clang.

It is pretty much dead code then. It would be a good idea to be a bit
more strict on this, i.e. not let archs linger in mainline if not
properly maintained. I would go even as far as requiring some public
CI logs for all architectures building -next/-rc as proof that some
configuration actually builds with some compiler, even if the compiler
is not an upstream one.

Cheers,
Miguel

[Brian Cain]

Nick, Arnd,

I can appreciate your frustration, I can see that I have let the community down here. I would like to keep hexagon in-tree and I am committed to making the changes necessary to do so. I have a patch under internal review to address the cited build issues and libgcc/compiler-rt content. In addition, my team has been focusing on developing QEMU system mode support that would mitigate some of the need for having hardware access. We have landed support for userspace hexagon-linux in upstream QEMU. My team and I want to make hexagon's open source footprint larger, not smaller. I realize that not being a good steward of the hexagon kernel has not helped, and we will do what we can to fix it.

-Brian

[Brian Cain]

> -----Original Message-----
> From: Arnd Bergmann <ar...@kernel.org>

...
> > There is no current gcc C compiler in the 3 locations that I know of to look.
> > The one I tried is v4.6 and it is too old to work with current makefiles.
>
> Correct, as I understand it , work on gcc was stopped after the 4.6 release
> and any testing internally to Qualcomm was done using a patched clang. A
> few years ago this was said to be (almost?) entirely upstream, but as Nick
> points out it has never been possible to build an upstream hexagon kernel
> with an upstream clang.

The critical missing component for a conventional build are implementations for compiler-emitted calls to builtins like __hexagon_memcpy_likely_aligned_min32bytes_mult8bytes, __hexagon_modsi3 -- these are available in the toolchain libraries (LIBGCC=libclang_rt.builtins-hexagon.a) but not in the kernel. This is easy to mitigate and yet disappointing that I did not do so before. I will do it.

There is a hexagon cross toolchain used for testing QEMU (userspace) guest code test cases. This same toolchain can be used to build the kernel. I will share a reference to that toolchain, standby.

-Brian

[Brian Cain]

> -----Original Message-----
> From: bcain=codeaur...@codeaurora.org
...
> There is a hexagon cross toolchain used for testing QEMU (userspace) guest
> code test cases. This same toolchain can be used to build the kernel. I will
> share a reference to that toolchain, standby.

It's published as a container in the Gitlab Container Registry. You can use docker/podman to pull "registry.gitlab.com/qemu-project/qemu/qemu/debian-hexagon-cross" in order to use it.

-Brian

[Nick Desaulniers]

I'm very happy to hear that.

> I have a patch under internal review to address the cited build issues and libgcc/compiler-rt content.

We'd be first in line to help build test such a patch. Please consider
cc'ing myself and clang-bu...@googlegroups.com when such a patch
is available externally. Further, we have the CI ready and waiting to
add new architectures, even if it's just build testing. That would
have caught regressions like 8320514c91bea; we were down to 1 build
failure with https://github.com/ClangBuiltLinux/linux/issues/759 last
I looked which was preventing us from adding Hexagon to any CI, but we
must now dig ourselves out of a slightly deeper hole now.

Is this patch something you suspect will take quite some time to work
through internal review?

> In addition, my team has been focusing on developing QEMU system mode support that would mitigate some of the need for having hardware access. We have landed support for userspace hexagon-linux in upstream QEMU.

That's also great to hear. QEMU is a critical part of our CI for boot
testing; if there's more info on timelines or what's involved with
booting a hexagon kernel in QEMU, we'd be very happy to know how or
when that's available.

> My team and I want to make hexagon's open source footprint larger, not smaller. I realize that not being a good steward of the hexagon kernel has not helped, and we will do what we can to fix it.

A worthwhile and appreciated sentiment. I believe you.

Hexagon could be an interesting case for LLVM support in general for
the Linux kernel; a case where each target or driver need not
necessarily have a GCC backend to be acceptable. But barring anyone
from being able to actually build it (let alone run it), it's not
that; it's less than that. It's dead code that bit rots further and
burdens maintainers who are maintaining something that's already
broken. I'm not sure who derives any benefit.

I think it's in everyone's best interest to see Linux support more
targets than fewer, and 2020 has been a hard year, but I'm curious how
long something has to be broken before folks say "enough." Please
let's support this properly or recognize the situation for what it is.
--
Thanks,
~Nick Desaulniers

[Randy Dunlap]

Hi Brian,

Maybe that will be useful to someone.

However, I am looking for something like a tarball that I can download
and deploy locally, like one can find at these locations:

https://toolchains.bootlin.com/
https://download.01.org/0day-ci/cross-package/
https://mirrors.edge.kernel.org/pub/tools/crosstool/


thanks.
--
~Randy

[Brian Cain]

> -----Original Message-----
> From: Randy Dunlap <rdu...@infradead.org>
...
> > It's published as a container in the Gitlab Container Registry. You can use
> docker/podman to pull "registry.gitlab.com/qemu-
> project/qemu/qemu/debian-hexagon-cross" in order to use it.
>
> Hi Brian,
>
> Maybe that will be useful to someone.
>
> However, I am looking for something like a tarball that I can download and
> deploy locally, like one can find at these locations:
>
> https://toolchains.bootlin.com/
> https://download.01.org/0day-ci/cross-package/
> https://mirrors.edge.kernel.org/pub/tools/crosstool/

Randy,

I 100% agree, I would prefer a tarball myself. I have been working with the team to produce the tarball and we haven't been able to deliver that yet. No good excuses here, only bad ones: somewhat tied up in process bureaucracy.

I can share the recipe that was used to build the toolchain in the container. No Dockerfile required, just a shell script w/mostly cmake + make commands. All of the sources are public, but musl is a downstream-public repo because we haven't landed the hexagon support in upstream musl yet.

-Brian

[Randy Dunlap]

Hi Brian,
I can wait. :)

Thanks.

[Brian Cain]

I don't think it should take long, no. I should have a better idea today of about how long it will take. We will share it ASAP.

> > In addition, my team has been focusing on developing QEMU system mode
> support that would mitigate some of the need for having hardware access.
> We have landed support for userspace hexagon-linux in upstream QEMU.
>
> That's also great to hear. QEMU is a critical part of our CI for boot testing; if
> there's more info on timelines or what's involved with booting a hexagon
> kernel in QEMU, we'd be very happy to know how or when that's available.
>
> > My team and I want to make hexagon's open source footprint larger, not
> smaller. I realize that not being a good steward of the hexagon kernel has not
> helped, and we will do what we can to fix it.
>
> A worthwhile and appreciated sentiment. I believe you.
>
> Hexagon could be an interesting case for LLVM support in general for the
> Linux kernel; a case where each target or driver need not necessarily have a
> GCC backend to be acceptable. But barring anyone from being able to actually
> build it (let alone run it), it's not that; it's less than that. It's dead code that bit
> rots further and burdens maintainers who are maintaining something that's
> already broken. I'm not sure who derives any benefit.
>
> I think it's in everyone's best interest to see Linux support more targets than
> fewer, and 2020 has been a hard year, but I'm curious how long something
> has to be broken before folks say "enough." Please let's support this properly
> or recognize the situation for what it is.

I don't think the special circumstances of 2020 are to blame, it's just my failure to give this work the priority it deserves. Agreed: we will support the target properly.

-Brian

[Brian Cain]

> -----Original Message-----
> From: Nick Desaulniers <ndesau...@google.com>
> Sent: Friday, April 23, 2021 4:40 PM
...
> We'd be first in line to help build test such a patch. Please consider
> cc'ing myself and clang-bu...@googlegroups.com when such a patch
> is available externally. Further, we have the CI ready and waiting to
> add new architectures, even if it's just build testing. That would
> have caught regressions like 8320514c91bea; we were down to 1 build
> failure with
> https://github.com/ClangBuiltLinux/linux/issues/759 last I looked
> which was preventing us from adding Hexagon to any CI, but we must now
> dig ourselves out of a slightly deeper hole now.
>
> Is this patch something you suspect will take quite some time to work
> through internal review?

These patches have completed their internal review. I have pushed them to my tree at git://git.kernel.org/pub/scm/linux/kernel/git/bcain/linux using for-linus branch, up to commit 43810cfdd2e6af9c57c0975e1b920f2b18c484b6 :

~~~~

commit 43810cfdd2e6af9c57c0975e1b920f2b18c484b6
Author: Sid Manning <sid...@codeaurora.org>
Date: Tue Oct 13 16:17:50 2020 -0500

Hexagon: add builtins to kernel

Add the compiler-rt builtins like memcpy to the hexagon kernel.

Signed-off-by: Sid Manning <sid...@codeaurora.org>
Signed-off-by: Brian Cain <bc...@codeaurora.org>

commit 19a75d4ece15d519036db9e52768e46ddc1dcecd
Author: Sid Manning <sid...@codeaurora.org>
Date: Mon Apr 26 22:38:31 2021 -0500

Hexagon: remove DEBUG from comet config

Remove CONFIG_DEBUG_INFO from comet configuration.

Signed-off-by: Sid Manning <sid...@codeaurora.org>
Signed-off-by: Brian Cain <bc...@codeaurora.org>

commit 4c8a34896e830ad02bf8cf4abe5b639e0de12938
Author: Sid Manning <sid...@codeaurora.org>
Date: Mon Apr 26 13:51:53 2021 -0500

Hexagon: change jumps to must-extend in futex_atomic_*

Cross-section jumps from .fixup section must be extended.

Signed-off-by: Sid Manning <sid...@codeaurora.org>
Signed-off-by: Brian Cain <bc...@codeaurora.org>

commit 9492ed9c4d146f2143f21b82aa8157a2787ad993
Author: Sid Manning <sid...@codeaurora.org>
Date: Fri Apr 23 15:06:58 2021 -0500

Hexagon: fix build errors

Fix type-o in ptrace.c.
Add missing include asm/hexagon_vm.h
Remove superfluous cast.
Replace 'p3_0' with 'preds'.

Signed-off-by: Sid Manning <sid...@codeaurora.org>
Signed-off-by: Brian Cain <bc...@codeaurora.org>

[Nick Desaulniers]

On Wed, Apr 28, 2021 at 9:09 AM Brian Cain <bc...@codeaurora.org> wrote:
>
> > -----Original Message-----
> > From: Nick Desaulniers <ndesau...@google.com>
> > Sent: Friday, April 23, 2021 4:40 PM
> ...
> > We'd be first in line to help build test such a patch. Please consider
> > cc'ing myself and clang-bu...@googlegroups.com when such a patch
> > is available externally. Further, we have the CI ready and waiting to
> > add new architectures, even if it's just build testing. That would
> > have caught regressions like 8320514c91bea; we were down to 1 build
> > failure with
> > https://github.com/ClangBuiltLinux/linux/issues/759 last I looked
> > which was preventing us from adding Hexagon to any CI, but we must now
> > dig ourselves out of a slightly deeper hole now.
> >
> > Is this patch something you suspect will take quite some time to work
> > through internal review?
>
> These patches have completed their internal review. I have pushed them to my tree at git://git.kernel.org/pub/scm/linux/kernel/git/bcain/linux using for-linus branch, up to commit 43810cfdd2e6af9c57c0975e1b920f2b18c484b6 :

Are you able to link these with lld? I see:

$ ARCH=hexagon CROSS_COMPILE=hexagon-linux-gnu make LLVM=1 LLVM_IAS=1

-j71 defconfig

$ ARCH=hexagon CROSS_COMPILE=hexagon-linux-gnu make LLVM=1 LLVM_IAS=1 -j71

...
LD .tmp_vmlinux.kallsyms1
ld.lld: error: vdso.c:(function vdso_init: .init.text+0x74):
relocation R_HEX_B22_PCREL out of range: 4010400 is not in [-2097152,
2097151]; references panic
>>> defined in kernel/built-in.a(panic.o)

ld.lld: error: cpu.c:(function cpuhp_threads_init: .init.text+0x4C):
relocation R_HEX_B22_PCREL out of range: 4009620 is not in [-2097152,
2097151]; references printk
>>> defined in kernel/built-in.a(printk/printk.o)
...
<many R_HEX_B22_PCREL out of range failures>

This is with llvm-project @ bdd68357901d.

(Looking at the builtins, I'm curious what are `:endloop0`, and `if`
like statements?)

--
Thanks,
~Nick Desaulniers

[Brian Cain]

> -----Original Message-----
> From: Nick Desaulniers <ndesau...@google.com>

> Sent: Wednesday, April 28, 2021 11:50 AM
> To: Brian Cain <bc...@codeaurora.org>

Sorry -- I used " KBUILD_CFLAGS_KERNEL=-mlong-calls". Sid, since this seems to be required maybe we should add it to the kernel build config?

[Brian Cain]

> -----Original Message-----
> From: Brian Cain <bc...@codeaurora.org>
> Sent: Wednesday, April 28, 2021 12:00 PM
> To: 'Nick Desaulniers' <ndesau...@google.com>

> Cc: 'clang-built-linux' <clang-bu...@googlegroups.com>;
> 'sid...@codeaurora.org' <sid...@codeaurora.org>; 'Manning, Sid'
> <sid...@quicinc.com>
> Subject: RE: FW: ARCH=hexagon unsupported?
>
>
>
> > -----Original Message-----
> > From: Nick Desaulniers <ndesau...@google.com>

> > Sent: Wednesday, April 28, 2021 11:50 AM

> > To: Brian Cain <bc...@codeaurora.org>
> > Cc: clang-built-linux <clang-bu...@googlegroups.com>;
> > sid...@codeaurora.org
> > Subject: Re: FW: ARCH=hexagon unsupported?
> >

> > On Wed, Apr 28, 2021 at 9:09 AM Brian Cain <bc...@codeaurora.org> wrote:
> > >
> > > > -----Original Message-----
> > > > From: Nick Desaulniers <ndesau...@google.com>
> > > > Sent: Friday, April 23, 2021 4:40 PM
> > > ...
> > > > We'd be first in line to help build test such a patch. Please
> > > > consider cc'ing myself and clang-bu...@googlegroups.com when
> > > > such a patch is available externally. Further, we have the CI
> > > > ready and waiting to add new architectures, even if it's just
> > > > build testing. That would have caught regressions like
> > > > 8320514c91bea; we were down to 1 build failure with
> > > > https://github.com/ClangBuiltLinux/linux/issues/759 last I looked
> > > > which was preventing us from adding Hexagon to any CI, but we must
> > > > now dig ourselves out of a slightly deeper hole now.
> > > >
> > > > Is this patch something you suspect will take quite some time to
> > > > work through internal review?
> > >
> > > These patches have completed their internal review. I have pushed
> > > them
> > to my tree at
> > git://git.kernel.org/pub/scm/linux/kernel/git/bcain/linux using
> > for-linus branch, up to commit
> > 43810cfdd2e6af9c57c0975e1b920f2b18c484b6
> > :
> >
> > Are you able to link these with lld? I see:
>

> Sorry -- I used " KBUILD_CFLAGS_KERNEL=-mlong-calls". Sid, since this seems
> to be required maybe we should add it to the kernel build config?
>
> >

...

> >
> > (Looking at the builtins, I'm curious what are `:endloop0`, and `if`
> > like
> > statements?)

":endloop0" is a packet attribute that marks the end of a hardware loop.
See PRM " Loop end " (8.2.2)

"if (p0) jump label" is an example of a conditional jump, " if (p0) r0 = memw(r2)" is an example of a conditional load. If the value of the predicate register is true, then the jump/load takes effect.
See PRM "Scalar predicates" (6.1)

https://developer.qualcomm.com/qfile/67417/80-n2040-45_b_qualcomm_hexagon_v67_programmer_reference_manual.pdf


-Brian

[Nick Desaulniers]

Yes, please. arch/hexagon/Makefile KBUILD_CFLAGS would be where to add
it I suspect.

> --
> You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-li...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/029a01d73c4f%24fa5d9940%24ef18cbc0%24%40codeaurora.org.



--
Thanks,
~Nick Desaulniers

[Brian Cain]

Done. Rebased for-linus. https://git.kernel.org/pub/scm/linux/kernel/git/bcain/linux.git/commit/?h=for-linus&id=38f974f061c5e7c83910bd287d2be8325476a3f9

Build log attached for reference.

-Brian

[Nick Desaulniers]

For the series:

Tested-by: Nick Desaulniers <ndesau...@google.com>

And that's the first time I've been able to build hexagon; nice work!

For the assembler sources, a common convention is to make the .S files
so the compiler implicitly adds `-x assembler-with-cpp` to run the C
pre processor. Then SYM_FUNC_START from include/linux/linkage.h should
be used. I think architectures are expected to define __ALIGN (5 for
hexagon) in their arch/{arch}/include/asm/linkage.h.

Otherwise, feel free to add my reviewed by tag to the first 3 (not
38f974f061c5e7c83910bd287d2be8325476a3f9).

Reviewed-by: Nick Desaulniers <ndesau...@google.com>

We can start on getting this wired up into our CI; we're doing a
(public) bug scrub today (right now), but I will revisit doing so
tomorrow.
--
Thanks,
~Nick Desaulniers

[Nick Desaulniers]

Example:
```
diff --git a/arch/hexagon/lib/divsi3.S b/arch/hexagon/lib/divsi3.S
index a2a6b33e0d53..04f07809f8b7 100644
--- a/arch/hexagon/lib/divsi3.S
+++ b/arch/hexagon/lib/divsi3.S
@@ -3,11 +3,10 @@
* Copyright (c) 2021, The Linux Foundation. All rights reserved.
*/

+#include <linux/linkage.h>
+
.text
-.p2align 5
-.globl __hexagon_divsi3
-.type __hexagon_divsi3, @function
-__hexagon_divsi3:
+SYM_FUNC_START(__hexagon_divsi3)
{
p0 = cmp.gt(r0,#-1)
p1 = cmp.gt(r1,#-1)
@@ -66,4 +65,4 @@ __hexagon_divsi3:
if (p3) r0 = sub(r1,r0)
jumpr r31
}
-.size __hexagon_divsi3, . - __hexagon_divsi3
+SYM_FUNC_END(__hexagon_divsi3)
```
Though preprocessing this file produces a `.align 4` directive, not
`.align 5`. Seems 2^4 is also what's defined in
arch/hexagon/include/asm/linkage.h. Should these be 2^4B aligned or
2^5B aligned?

>
> Otherwise, feel free to add my reviewed by tag to the first 3 (not
> 38f974f061c5e7c83910bd287d2be8325476a3f9).
>
> Reviewed-by: Nick Desaulniers <ndesau...@google.com>
>
> We can start on getting this wired up into our CI; we're doing a
> (public) bug scrub today (right now), but I will revisit doing so
> tomorrow.
> --
> Thanks,
> ~Nick Desaulniers

--
Thanks,
~Nick Desaulniers

[Arnd Bergmann]

On Wed, Apr 28, 2021 at 9:50 PM 'Nick Desaulniers' via Clang Built
Linux <clang-bu...@googlegroups.com> wrote:
> On Wed, Apr 28, 2021 at 12:30 PM Brian Cain <bc...@codeaurora.org> wrote:
> Tested-by: Nick Desaulniers <ndesau...@google.com>
>
> And that's the first time I've been able to build hexagon; nice work!
>

I built a defconfig kernel with my test tree and clang-12 now, that worked fine.
However using clang-13 I got one warning and one internal error:

/git/arm-soc/block/blk-mq.c:631:39: error: passing 4-byte aligned
argument to 16-byte aligned parameter 2 of
'smp_call_function_single_async' may result in an unaligned pointer
access [-Werror,-Walign-mismatch]
smp_call_function_single_async(cpu, &rq->csd);
^
1 error generated.
make[3]: *** [/git/arm-soc/scripts/Makefile.build:273: block/blk-mq.o] Error 1
make[3]: Target '__build' not remade because of errors.
make[2]: *** [/git/arm-soc/Makefile:1943: block] Error 2
PLEASE submit a bug report to https://bugs.llvm.org/ and include the
crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: clang-13 -Wp,-MMD,net/core/.dev.o.d -nostdinc
-isystem /usr/lib/llvm-13/lib/clang/13.0.0/include
-I/git/arm-soc/arch/hexagon/include -I./arch/hexagon/include/generated
-I/git/arm-soc/include -I./include
-I/git/arm-soc/arch/hexagon/include/uapi
-I./arch/hexagon/include/generated/uapi -I/git/arm-soc/include/uapi
-I./include/generated/uapi -include
/git/arm-soc/include/linux/compiler-version.h -include
/git/arm-soc/include/linux/kconfig.h -include
/git/arm-soc/include/linux/compiler_types.h -D__KERNEL__
-fmacro-prefix-map=/git/arm-soc/= -DKBUILD_ERR0 -Wall -Wundef
-Werror=strict-prototypes -fno-strict-aliasing -fno-common
-fshort-wchar -fno-PIE -Werror=implicit-function-declaration
-Werror=implicit-int -Werror=return-type -std=gnu89
-Werror=unknown-warning-option --target=hexagon-linux -integrated-as
-G0 -fno-short-enums -mlong-calls -ffixed-r19 -DTHREADINFO_REG=r19
-D__linux__ -fno-delete-null-pointer-checks -O2 -fno-stack-protector
-fno-omit-frame-pointer -fno-optimize-sibling-calls
-mno-omit-leaf-frame-pointer -g -Wdeclaration-after-statement -Wvla
-fno-strict-overflow -fno-stack-check -Werror=date-time
-Werror=incompatible-pointer-types -Werror -I /git/arm-soc/net/core -I
./net/core -DKBUILD_MODFILE=\"net/core/dev\" -DKBUILD_BASENAME=\"dev\"
-DKBUILD_MODNAME=\"dev\" -D__KBUILD_MODNAME=kmod_dev -c -o
net/core/dev.o /git/arm-soc/net/core/dev.c
1. <eof> parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module '/git/arm-soc/net/core/dev.c'.
4. Running pass 'Prologue/Epilogue Insertion & Frame Finalization' on
function '@netdev_bind_sb_channel_queue'
#0 0x00007f22c816fae3 llvm::sys::PrintStackTrace(llvm::raw_ostream&,
int) (/lib/x86_64-linux-gnu/libLLVM-13.so.1+0xc07ae3)
#1 0x00007f22c816ded0 llvm::sys::RunSignalHandlers()
(/lib/x86_64-linux-gnu/libLLVM-13.so.1+0xc05ed0)
#2 0x00007f22c80b7a36 (/lib/x86_64-linux-gnu/libLLVM-13.so.1+0xb4fa36)
#3 0x00007f22d00091f0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x141f0)
#4 0x00007f22c8500e1e
llvm::MachineRegisterInfo::addRegOperandToUseList(llvm::MachineOperand*)
(/lib/x86_64-linux-gnu/libLLVM-13.so.1+0xf98e1e)
#5 0x00007f22c848ff4a
llvm::MachineInstr::AddRegOperandsToUseLists(llvm::MachineRegisterInfo&)
(/lib/x86_64-linux-gnu/libLLVM-13.so.1+0xf27f4a)
#6 0x00007f22c843936e
llvm::ilist_traits<llvm::MachineInstr>::addNodeToList(llvm::MachineInstr*)
(/lib/x86_64-linux-gnu/libLLVM-13.so.1+0xed136e)
#7 0x00007f22c857af64 (/lib/x86_64-linux-gnu/libLLVM-13.so.1+0x1012f64)
#8 0x00007f22c848b87e
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(/lib/x86_64-linux-gnu/libLLVM-13.so.1+0xf2387e)
#9 0x00007f22c829823d
llvm::FPPassManager::runOnFunction(llvm::Function&)
(/lib/x86_64-linux-gnu/libLLVM-13.so.1+0xd3023d)
#10 0x00007f22c829dd23 llvm::FPPassManager::runOnModule(llvm::Module&)
(/lib/x86_64-linux-gnu/libLLVM-13.so.1+0xd35d23)
#11 0x00007f22c829888f
llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/lib/x86_64-linux-gnu/libLLVM-13.so.1+0xd3088f)
#12 0x00007f22ce4c6561 (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0x176f561)
#13 0x00007f22ce4c044b
clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&,
clang::TargetOptions const&, clang::LangOptions const&,
llvm::DataLayout const&, llvm::Module*, clang::BackendAction,
std::unique_ptr<llvm::raw_pwrite_stream,
std::default_delete<llvm::raw_pwrite_stream> >)
(/lib/x86_64-linux-gnu/libclang-cpp.so.13+0x176944b)
#14 0x00007f22ce75fcf8 (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0x1a08cf8)
#15 0x00007f22cd804df4 clang::ParseAST(clang::Sema&, bool, bool)
(/lib/x86_64-linux-gnu/libclang-cpp.so.13+0xaaddf4)
#16 0x00007f22cef03728 clang::FrontendAction::Execute()
(/lib/x86_64-linux-gnu/libclang-cpp.so.13+0x21ac728)
#17 0x00007f22cee878b1
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/lib/x86_64-linux-gnu/libclang-cpp.so.13+0x21308b1)
#18 0x00007f22cef6aac2
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/lib/x86_64-linux-gnu/libclang-cpp.so.13+0x2213ac2)
#19 0x0000000000412f39 cc1_main(llvm::ArrayRef<char const*>, char
const*, void*) (/usr/lib/llvm-13/bin/clang+0x412f39)
#20 0x0000000000410f05 (/usr/lib/llvm-13/bin/clang+0x410f05)
#21 0x00007f22cebc0ac2 (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0x1e69ac2)
#22 0x00007f22c80b780d
llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>)
(/lib/x86_64-linux-gnu/libLLVM-13.so.1+0xb4f80d)
#23 0x00007f22cebc058a
clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef>
>, std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >*, bool*) const
(/lib/x86_64-linux-gnu/libclang-cpp.so.13+0x1e6958a)
#24 0x00007f22ceb954af
clang::driver::Compilation::ExecuteCommand(clang::driver::Command
const&, clang::driver::Command const*&) const
(/lib/x86_64-linux-gnu/libclang-cpp.so.13+0x1e3e4af)
#25 0x00007f22ceb95867
clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&,
llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>
>&) const (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0x1e3e867)
#26 0x00007f22cebaa2ad
clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&,
llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>
>&) (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0x1e532ad)
#27 0x00000000004107af main (/usr/lib/llvm-13/bin/clang+0x4107af)
#28 0x00007f22c7020565 __libc_start_main ./csu/../csu/libc-start.c:332:16
#29 0x000000000040df4e _start (/usr/lib/llvm-13/bin/clang+0x40df4e)
clang: error: clang frontend command failed with exit code 139 (use -v
to see invocation)
Ubuntu clang version
13.0.0-++20210427083533+8de7d8b2c289-1~exp1~20210427184256.368
Target: hexagon-unknown-linux
Thread model: posix
InstalledDir: /usr/bin
clang: note: diagnostic msg:
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/dev-c62fd4.c
clang: note: diagnostic msg: /tmp/dev-c62fd4.sh
clang: note: diagnostic msg:
********************
make[4]: *** [/git/arm-soc/scripts/Makefile.build:273: net/core/dev.o] Error 139
8<-------------------



Trying to build allmodconfig using clang-12 resulted in a different
internal error:

/git/arm-soc/drivers/clocksource/timer-oxnas-rps.c:39:9: error:
'TIMER_ENABLE' macro redefined [-Werror,-Wmacro-redefined]
fatal error: error in backend: Misaligned constant address: 0x00000007
has alignment 1, but the memory access requires 4
PLEASE submit a bug report to https://bugs.llvm.org/ and include the
crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: clang-12 -Wp,-MMD,kernel/locking/.lockdep.o.d
-nostdinc -isystem /usr/lib/llvm-12/lib/clang/12.0.0/include
-I/git/arm-soc/arch/hexagon/include -I./arch/hexagon/include/generated
-I/git/arm-soc/include -I./include
-I/git/arm-soc/arch/hexagon/include/uapi
-I./arch/hexagon/include/generated/uapi -I/git/arm-soc/include/uapi
-I./include/generated/uapi -include
/git/arm-soc/include/linux/compiler-version.h -include
/git/arm-soc/include/linux/kconfig.h -include
/git/arm-soc/include/linux/compiler_types.h -D__KERNEL__
-fmacro-prefix-map=/git/arm-soc/= -DKBUILD_ERR0 -Wall -Wundef
-Werror=strict-prototypes -fno-strict-aliasing -fno-common
-fshort-wchar -fno-PIE -Werror=implicit-function-declaration
-Werror=implicit-int -Werror=return-type -std=gnu89
-Werror=unknown-warning-option --target=hexagon-linux -integrated-as
-G0 -fno-short-enums -mlong-calls -ffixed-r19 -DTHREADINFO_REG=r19
-D__linux__ -fno-delete-null-pointer-checks -O2
-Wframe-larger-than=1024 -fno-stack-protector -fno-omit-frame-pointer
-fno-optimize-sibling-calls -mno-omit-leaf-frame-pointer
-ftrivial-auto-var-init=pattern -falign-functions=32
-Wdeclaration-after-statement -Wvla -fno-strict-overflow
-fno-stack-check -Werror=date-time -Werror=incompatible-pointer-types
-Werror -I /git/arm-soc/kernel/locking -I ./kernel/locking
-DKBUILD_MODFILE=\"kernel/locking/lockdep\"
-DKBUILD_BASENAME=\"lockdep\" -DKBUILD_MODNAME=\"lockdep\"
-D__KBUILD_MODNAME=kmod_lockdep -c -o kernel/locking/lockdep.o
/git/arm-soc/kernel/locking/lockdep.c
1. <eof> parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module
'/git/arm-soc/kernel/locking/lockdep.c'.
4. Running pass 'Hexagon DAG->DAG Pattern Instruction Selection' on
function '@validate_chain'
#0 0x00007fde5bd81a43 llvm::sys::PrintStackTrace(llvm::raw_ostream&,
int) (/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xbd9a43)
#1 0x00007fde5bd7fd50 llvm::sys::RunSignalHandlers()
(/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xbd7d50)
#2 0x00007fde5bcd0c2a (/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xb28c2a)
#3 0x00007fde5bcd0bcb (/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xb28bcb)
#4 0x00007fde5bd7c817 llvm::sys::Process::Exit(int, bool)
(/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xbd4817)
#5 0x0000000000412ad0 (/usr/lib/llvm-12/bin/clang+0x412ad0)
#6 0x00007fde5bcdcb12 llvm::report_fatal_error(llvm::Twine const&,
bool) (/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xb34b12)
#7 0x00007fde5bcdcbe7 (/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xb34be7)
#8 0x00007fde5daccb03 (/lib/x86_64-linux-gnu/libLLVM-12.so.1+0x2924b03)
#9 0x00007fde5dad1fed (/lib/x86_64-linux-gnu/libLLVM-12.so.1+0x2929fed)
#10 0x00007fde5dad34bf (/lib/x86_64-linux-gnu/libLLVM-12.so.1+0x292b4bf)
#11 0x00007fde5c33b2a0 (/lib/x86_64-linux-gnu/libLLVM-12.so.1+0x11932a0)
#12 0x00007fde5c33a325 llvm::SelectionDAG::Legalize()
(/lib/x86_64-linux-gnu/libLLVM-12.so.1+0x1192325)
#13 0x00007fde5c46d0d5 llvm::SelectionDAGISel::CodeGenAndEmitDAG()
(/lib/x86_64-linux-gnu/libLLVM-12.so.1+0x12c50d5)
#14 0x00007fde5c46c58a
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&)
(/lib/x86_64-linux-gnu/libLLVM-12.so.1+0x12c458a)
#15 0x00007fde5c46a2c6
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&)
(/lib/x86_64-linux-gnu/libLLVM-12.so.1+0x12c22c6)
#16 0x00007fde5dab5d24 (/lib/x86_64-linux-gnu/libLLVM-12.so.1+0x290dd24)
#17 0x00007fde5c08e43e
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xee643e)
#18 0x00007fde5bea94ad
llvm::FPPassManager::runOnFunction(llvm::Function&)
(/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xd014ad)
#19 0x00007fde5beaee93 llvm::FPPassManager::runOnModule(llvm::Module&)
(/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xd06e93)
#20 0x00007fde5bea9aff
llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xd01aff)
#21 0x00007fde61edb6f6
clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&,
clang::TargetOptions const&, clang::LangOptions const&,
llvm::DataLayout const&, llvm::Module*, clang::BackendAction,
std::unique_ptr<llvm::raw_pwrite_stream,
std::default_delete<llvm::raw_pwrite_stream> >)
(/lib/x86_64-linux-gnu/libclang-cpp.so.12+0x15446f6)
#22 0x00007fde621748af (/lib/x86_64-linux-gnu/libclang-cpp.so.12+0x17dd8af)
#23 0x00007fde612cfb64 clang::ParseAST(clang::Sema&, bool, bool)
(/lib/x86_64-linux-gnu/libclang-cpp.so.12+0x938b64)
#24 0x00007fde62868d48 clang::FrontendAction::Execute()
(/lib/x86_64-linux-gnu/libclang-cpp.so.12+0x1ed1d48)
#25 0x00007fde627f67d1
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/lib/x86_64-linux-gnu/libclang-cpp.so.12+0x1e5f7d1)
#26 0x00007fde628cbd62
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/lib/x86_64-linux-gnu/libclang-cpp.so.12+0x1f34d62)
#27 0x00000000004127e2 cc1_main(llvm::ArrayRef<char const*>, char
const*, void*) (/usr/lib/llvm-12/bin/clang+0x4127e2)
#28 0x0000000000410b5e (/usr/lib/llvm-12/bin/clang+0x410b5e)
#29 0x00007fde625126c2 (/lib/x86_64-linux-gnu/libclang-cpp.so.12+0x1b7b6c2)
#30 0x00007fde5bcd0bad
llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>)
(/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xb28bad)
#31 0x00007fde62511eb9
clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef>
>, std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >*, bool*) const
(/lib/x86_64-linux-gnu/libclang-cpp.so.12+0x1b7aeb9)
#32 0x00007fde624e746f
clang::driver::Compilation::ExecuteCommand(clang::driver::Command
const&, clang::driver::Command const*&) const
(/lib/x86_64-linux-gnu/libclang-cpp.so.12+0x1b5046f)
#33 0x00007fde624e7827
clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&,
llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>
>&) const (/lib/x86_64-linux-gnu/libclang-cpp.so.12+0x1b50827)
#34 0x00007fde624fc20c
clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&,
llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>
>&) (/lib/x86_64-linux-gnu/libclang-cpp.so.12+0x1b6520c)
#35 0x0000000000410434 main (/usr/lib/llvm-12/bin/clang+0x410434)
#36 0x00007fde5ac60565 __libc_start_main ./csu/../csu/libc-start.c:332:16
#37 0x000000000040dd1e _start (/usr/lib/llvm-12/bin/clang+0x40dd1e)
clang: error: clang frontend command failed with exit code 70 (use -v
to see invocation)
Ubuntu clang version 12.0.0-1ubuntu1
Target: hexagon-unknown-linux
Thread model: posix
InstalledDir: /usr/bin
clang: note: diagnostic msg:
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/lockdep-62da10.c
clang: note: diagnostic msg: /tmp/lockdep-62da10.sh
clang: note: diagnostic msg:

********************
make[4]: *** [/git/arm-soc/scripts/Makefile.build:273:
kernel/locking/lockdep.o] Error 70
fatal error: error in backend: Cannot select: 0x35266d0: i64,ch =
load<(load 1 from %fixed-stack.1, align 8), sext from i1> 0x2cbb478,
FrameIndex:i32<-1>, undef:i32
0x35269a8: i32 = FrameIndex<-1>
0x3519548: i32 = undef
In function: dm_bitset_resize
PLEASE submit a bug report to https://bugs.llvm.org/ and include the
crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: clang-12
-Wp,-MMD,drivers/md/persistent-data/.dm-bitset.o.d -nostdinc -isystem
/usr/lib/llvm-12/lib/clang/12.0.0/include
-I/git/arm-soc/arch/hexagon/include -I./arch/hexagon/include/generated
-I/git/arm-soc/include -I./include
-I/git/arm-soc/arch/hexagon/include/uapi
-I./arch/hexagon/include/generated/uapi -I/git/arm-soc/include/uapi
-I./include/generated/uapi -include
/git/arm-soc/include/linux/compiler-version.h -include
/git/arm-soc/include/linux/kconfig.h -include
/git/arm-soc/include/linux/compiler_types.h -D__KERNEL__
-fmacro-prefix-map=/git/arm-soc/= -DKBUILD_ERR0 -Wall -Wundef
-Werror=strict-prototypes -fno-strict-aliasing -fno-common
-fshort-wchar -fno-PIE -Werror=implicit-function-declaration
-Werror=implicit-int -Werror=return-type -std=gnu89
-Werror=unknown-warning-option --target=hexagon-linux -integrated-as
-G0 -fno-short-enums -mlong-calls -ffixed-r19 -DTHREADINFO_REG=r19
-D__linux__ -fno-delete-null-pointer-checks -O2
-Wframe-larger-than=1024 -fno-stack-protector -fno-omit-frame-pointer
-fno-optimize-sibling-calls -mno-omit-leaf-frame-pointer
-ftrivial-auto-var-init=pattern -falign-functions=32
-Wdeclaration-after-statement -Wvla -fno-strict-overflow
-fno-stack-check -Werror=date-time -Werror=incompatible-pointer-types
-Werror -I /git/arm-soc/drivers/md/persistent-data -I
./drivers/md/persistent-data -DMODULE -mlong-calls
-DKBUILD_BASENAME=\"dm_bitset\"
-DKBUILD_MODNAME=\"dm_persistent_data\"
-D__KBUILD_MODNAME=kmod_dm_persistent_data -c -o
drivers/md/persistent-data/dm-bitset.o
/git/arm-soc/drivers/md/persistent-data/dm-bitset.c
1. <eof> parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module
'/git/arm-soc/drivers/md/persistent-data/dm-bitset.c'.
4. Running pass 'Hexagon DAG->DAG Pattern Instruction Selection' on
function '@dm_bitset_resize'
#0 0x00007f375591fa43 llvm::sys::PrintStackTrace(llvm::raw_ostream&,
int) (/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xbd9a43)
#1 0x00007f375591dd50 llvm::sys::RunSignalHandlers()
(/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xbd7d50)
#2 0x00007f375586ec2a (/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xb28c2a)
#3 0x00007f375586ebcb (/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xb28bcb)
#4 0x00007f375591a817 llvm::sys::Process::Exit(int, bool)
(/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xbd4817)
#5 0x0000000000412ad0 (/usr/lib/llvm-12/bin/clang+0x412ad0)
#6 0x00007f375587ab12 llvm::report_fatal_error(llvm::Twine const&,
bool) (/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xb34b12)
#7 0x00007f375587abe7 (/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xb34be7)
#8 0x00007f375601321c (/lib/x86_64-linux-gnu/libLLVM-12.so.1+0x12cd21c)
#9 0x00007f375601296d (/lib/x86_64-linux-gnu/libLLVM-12.so.1+0x12cc96d)
#10 0x00007f375764ba34 (/lib/x86_64-linux-gnu/libLLVM-12.so.1+0x2905a34)
#11 0x00007f375600badf
llvm::SelectionDAGISel::DoInstructionSelection()
(/lib/x86_64-linux-gnu/libLLVM-12.so.1+0x12c5adf)
#12 0x00007f375600b200 llvm::SelectionDAGISel::CodeGenAndEmitDAG()
(/lib/x86_64-linux-gnu/libLLVM-12.so.1+0x12c5200)
#13 0x00007f375600a58a
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&)
(/lib/x86_64-linux-gnu/libLLVM-12.so.1+0x12c458a)
#14 0x00007f37560082c6
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&)
(/lib/x86_64-linux-gnu/libLLVM-12.so.1+0x12c22c6)
#15 0x00007f3757653d24 (/lib/x86_64-linux-gnu/libLLVM-12.so.1+0x290dd24)
#16 0x00007f3755c2c43e
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xee643e)
#17 0x00007f3755a474ad
llvm::FPPassManager::runOnFunction(llvm::Function&)
(/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xd014ad)
#18 0x00007f3755a4ce93 llvm::FPPassManager::runOnModule(llvm::Module&)
(/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xd06e93)
#19 0x00007f3755a47aff
llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xd01aff)
#20 0x00007f375ba796f6
clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&,
clang::TargetOptions const&, clang::LangOptions const&,
llvm::DataLayout const&, llvm::Module*, clang::BackendAction,
std::unique_ptr<llvm::raw_pwrite_stream,
std::default_delete<llvm::raw_pwrite_stream> >)
(/lib/x86_64-linux-gnu/libclang-cpp.so.12+0x15446f6)
#21 0x00007f375bd128af (/lib/x86_64-linux-gnu/libclang-cpp.so.12+0x17dd8af)
#22 0x00007f375ae6db64 clang::ParseAST(clang::Sema&, bool, bool)
(/lib/x86_64-linux-gnu/libclang-cpp.so.12+0x938b64)
#23 0x00007f375c406d48 clang::FrontendAction::Execute()
(/lib/x86_64-linux-gnu/libclang-cpp.so.12+0x1ed1d48)
#24 0x00007f375c3947d1
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/lib/x86_64-linux-gnu/libclang-cpp.so.12+0x1e5f7d1)
#25 0x00007f375c469d62
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/lib/x86_64-linux-gnu/libclang-cpp.so.12+0x1f34d62)
#26 0x00000000004127e2 cc1_main(llvm::ArrayRef<char const*>, char
const*, void*) (/usr/lib/llvm-12/bin/clang+0x4127e2)
#27 0x0000000000410b5e (/usr/lib/llvm-12/bin/clang+0x410b5e)
#28 0x00007f375c0b06c2 (/lib/x86_64-linux-gnu/libclang-cpp.so.12+0x1b7b6c2)
#29 0x00007f375586ebad
llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>)
(/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xb28bad)
#30 0x00007f375c0afeb9
clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef>
>, std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >*, bool*) const
(/lib/x86_64-linux-gnu/libclang-cpp.so.12+0x1b7aeb9)
#31 0x00007f375c08546f
clang::driver::Compilation::ExecuteCommand(clang::driver::Command
const&, clang::driver::Command const*&) const
(/lib/x86_64-linux-gnu/libclang-cpp.so.12+0x1b5046f)
#32 0x00007f375c085827
clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&,
llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>
>&) const (/lib/x86_64-linux-gnu/libclang-cpp.so.12+0x1b50827)
#33 0x00007f375c09a20c
clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&,
llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>
>&) (/lib/x86_64-linux-gnu/libclang-cpp.so.12+0x1b6520c)
#34 0x0000000000410434 main (/usr/lib/llvm-12/bin/clang+0x410434)
#35 0x00007f37547fe565 __libc_start_main ./csu/../csu/libc-start.c:332:16
#36 0x000000000040dd1e _start (/usr/lib/llvm-12/bin/clang+0x40dd1e)
clang: error: clang frontend command failed with exit code 70 (use -v
to see invocation)
Ubuntu clang version 12.0.0-1ubuntu1

Arnd

[Brian Cain]

> -----Original Message-----
> From: Arnd Bergmann <ar...@kernel.org>
> Sent: Wednesday, April 28, 2021 3:57 PM
> To: Nick Desaulniers <ndesau...@google.com>

> Cc: Brian Cain <bc...@codeaurora.org>; clang-built-linux <clang-built-
> li...@googlegroups.com>; sid...@codeaurora.org; Manning, Sid
> <sid...@quicinc.com>
> Subject: Re: FW: ARCH=hexagon unsupported?
>

> On Wed, Apr 28, 2021 at 9:50 PM 'Nick Desaulniers' via Clang Built
> Linux <clang-bu...@googlegroups.com> wrote:
> > On Wed, Apr 28, 2021 at 12:30 PM Brian Cain <bc...@codeaurora.org>
> wrote:
> > Tested-by: Nick Desaulniers <ndesau...@google.com>
> >
> > And that's the first time I've been able to build hexagon; nice work!
> >
>
> I built a defconfig kernel with my test tree and clang-12 now, that worked fine.
> However using clang-13 I got one warning and one internal error:

...

Thanks for testing this! Looks like a healthy pile of toolchain bugs on trunk. I will look into reducing these for the compiler team and motivate them to get some fixes.

-Brian

[Arnd Bergmann]

On Wed, Apr 28, 2021 at 10:56 PM Arnd Bergmann <ar...@kernel.org> wrote:

> Trying to build allmodconfig using clang-12 resulted in a different
> internal error:

I tried one more thing: turning off anything that failed to compile gave me
this link error:


ld.lld: error: undefined symbol: __divsi3
>>> referenced by hexagon_ksyms.c
>>> hexagon_ksyms.o:(__ksymtab___divsi3) in archive arch/hexagon/kernel/built-in.a

ld.lld: error: undefined symbol: __modsi3
>>> referenced by hexagon_ksyms.c
>>> hexagon_ksyms.o:(__ksymtab___modsi3) in archive arch/hexagon/kernel/built-in.a

ld.lld: error: undefined symbol: __udivsi3
>>> referenced by hexagon_ksyms.c
>>> hexagon_ksyms.o:(__ksymtab___udivsi3) in archive arch/hexagon/kernel/built-in.a

ld.lld: error: undefined symbol: __umodsi3
>>> referenced by hexagon_ksyms.c
>>> hexagon_ksyms.o:(__ksymtab___umodsi3) in archive arch/hexagon/kernel/built-in.a

ld.lld: error: undefined symbol: __irqentry_text_start
>>> referenced by stackdepot.c
>>> stackdepot.o:(filter_irq_stacks) in archive lib/built-in.a
>>> referenced by stackdepot.c
>>> stackdepot.o:(filter_irq_stacks) in archive lib/built-in.a

ld.lld: error: undefined symbol: __irqentry_text_end
>>> referenced by stackdepot.c
>>> stackdepot.o:(filter_irq_stacks) in archive lib/built-in.a
>>> referenced by stackdepot.c
>>> stackdepot.o:(filter_irq_stacks) in archive lib/built-in.a

ld.lld: error: undefined symbol: __softirqentry_text_start
>>> referenced by stackdepot.c
>>> stackdepot.o:(filter_irq_stacks) in archive lib/built-in.a
>>> referenced by stackdepot.c
>>> stackdepot.o:(filter_irq_stacks) in archive lib/built-in.a

ld.lld: error: undefined symbol: __softirqentry_text_end
>>> referenced by stackdepot.c
>>> stackdepot.o:(filter_irq_stacks) in archive lib/built-in.a
>>> referenced by stackdepot.c
>>> stackdepot.o:(filter_irq_stacks) in archive lib/built-in.a

[Nick Desaulniers]

On Wed, Apr 28, 2021 at 1:57 PM Arnd Bergmann <ar...@kernel.org> wrote:
>
> On Wed, Apr 28, 2021 at 9:50 PM 'Nick Desaulniers' via Clang Built
> Linux <clang-bu...@googlegroups.com> wrote:
> > On Wed, Apr 28, 2021 at 12:30 PM Brian Cain <bc...@codeaurora.org> wrote:
> > Tested-by: Nick Desaulniers <ndesau...@google.com>
> >
> > And that's the first time I've been able to build hexagon; nice work!
> >
>
> I built a defconfig kernel with my test tree and clang-12 now, that worked fine.
> However using clang-13 I got one warning and one internal error:
>
> /git/arm-soc/block/blk-mq.c:631:39: error: passing 4-byte aligned
> argument to 16-byte aligned parameter 2 of
> 'smp_call_function_single_async' may result in an unaligned pointer
> access [-Werror,-Walign-mismatch]
> smp_call_function_single_async(cpu, &rq->csd);
> ^

For this warning, maybe you could help us encourage Jens to make a
decision, one way or another? Or have a good idea yourself on which
approach would be best?
https://lore.kernel.org/linux-block/CAKwvOdmoud9=Uf2xN7q1c1gP06ZNU4K...@mail.gmail.com/
https://lore.kernel.org/linux-block/20210310225240.4epj2mdmzt4vurr3@archlinux-ax161/
https://github.com/ClangBuiltLinux/linux/issues/1328

Not sure we can go back and fix things for clang-12, though the point
release will be coming up. Maybe making this dependent on clang-13 is
the way to go for now?
--
Thanks,
~Nick Desaulniers

[Brian Cain]

> -----Original Message-----
> From: Arnd Bergmann <ar...@kernel.org>

...
> On Wed, Apr 28, 2021 at 10:56 PM Arnd Bergmann <ar...@kernel.org> wrote:
>
> > Trying to build allmodconfig using clang-12 resulted in a different
> > internal error:
>
> I tried one more thing: turning off anything that failed to compile gave me this
> link error:

...

> ld.lld: error: undefined symbol: __umodsi3
> >>> referenced by hexagon_ksyms.c
> >>> hexagon_ksyms.o:(__ksymtab___umodsi3) in archive
> >>> arch/hexagon/kernel/built-in.a

Good catch, thanks. These should be corrected in the builtins patch.

But the ones below aren't as obvious. I'll look deeper.

[Brian Cain]

Thanks! I have incorporated your feedback. Turns out we didn't need a special override of SYM_FUNC_START/etc -- we just needed to use the existing arch-independent definition.

https://git.kernel.org/pub/scm/linux/kernel/git/bcain/linux.git/commit/?h=for-linus&id=0ff72a0e4abdeb1b86ad3d8f6ba62c91b37789a3

-Brian

[Nick Desaulniers]

For the series:
Reviewed-by: Nick Desaulniers <ndesau...@google.com>

Are you going to send this to Linus as part of the merge window that
is open right now?

I've started wiring this up to our CI now in:
https://github.com/ClangBuiltLinux/continuous-integration2/pull/125
We'll have to wait for Linaro's remote build service "tuxsuite" to support this:
https://gitlab.com/Linaro/tuxsuite/-/issues/107

The next steps for us that would be of interest is boot testing under
emulation in CI. Our current setup for all arches relies on qemu and
buildroot. We're not doing any testing more extensive than power up
the machine, then power down the machine at the moment; if it takes
longer than 3m to do so, even under emulation, the machine is probably
hung and is considered a test failure.

You mentioned qemu work earlier, but only userspace? Are there plans
to develop a qemu-system-hexagon? If so, what's the progress or any
timeline look like for that?

Buildroot is a tall order; if needed we can simply use our own binary
as init to initiate poweroff, though I guess then at that point the
question would be which libcs have hexagon support that you recommend?
--
Thanks,
~Nick Desaulniers

[Brian Cain]

> -----Original Message-----
> From: Nick Desaulniers <ndesau...@google.com>
...
> Are you going to send this to Linus as part of the merge window that is open
> right now?

Yes.

> I've started wiring this up to our CI now in:
> https://github.com/ClangBuiltLinux/continuous-integration2/pull/125
> We'll have to wait for Linaro's remote build service "tuxsuite" to support this:
> https://gitlab.com/Linaro/tuxsuite/-/issues/107

Excellent, this sounds useful.

> The next steps for us that would be of interest is boot testing under emulation
> in CI. Our current setup for all arches relies on qemu and buildroot. We're not
> doing any testing more extensive than power up the machine, then power
> down the machine at the moment; if it takes longer than 3m to do so, even
> under emulation, the machine is probably hung and is considered a test
> failure.
>
> You mentioned qemu work earlier, but only userspace? Are there plans to
> develop a qemu-system-hexagon? If so, what's the progress or any timeline
> look like for that?

We have qemu-system-hexagon "working" downstream. Still working out some kinks to make it robust, but we have done something like your shutdown-on-startup test. Upstreaming has a few roadblocks:
- publish boot rom image
- compiler+assembler upstreaming work to support system opcodes and registers
- review/publish the system architecture specification
- musl upstreaming (in progress - https://www.openwall.com/lists/musl/2021/03/09/9 )

I'll see if I can project an estimate for all of this to come together.

> Buildroot is a tall order; if needed we can simply use our own binary as init to
> initiate poweroff, though I guess then at that point the question would be
> which libcs have hexagon support that you recommend?

https://github.com/quic/musl is the only place we have support thus far.

-Brian

[Nick Desaulniers]

On Thu, Apr 29, 2021 at 11:25 AM Brian Cain <bc...@codeaurora.org> wrote:
>
> > The next steps for us that would be of interest is boot testing under emulation
> > in CI. Our current setup for all arches relies on qemu and buildroot. We're not
> > doing any testing more extensive than power up the machine, then power
> > down the machine at the moment; if it takes longer than 3m to do so, even
> > under emulation, the machine is probably hung and is considered a test
> > failure.
> >
> > You mentioned qemu work earlier, but only userspace? Are there plans to
> > develop a qemu-system-hexagon? If so, what's the progress or any timeline
> > look like for that?
>
> We have qemu-system-hexagon "working" downstream. Still working out some kinks to make it robust, but we have done something like your shutdown-on-startup test. Upstreaming has a few roadblocks:
> - publish boot rom image
> - compiler+assembler upstreaming work to support system opcodes and registers
> - review/publish the system architecture specification
> - musl upstreaming (in progress - https://www.openwall.com/lists/musl/2021/03/09/9 )
>
> I'll see if I can project an estimate for all of this to come together.

Nice, lots of moving pieces; you all are very busy. Even if it's not
yet upstreamed, but available publicly, we've shipped our own builds
of qemu in our CI when distro package maintainers lagged the cutting
edge we occasionally needed. We could use that, with the caveat
"please work on upstreaming this so we don't have to carry it
forever."

Is the qemu work dependent on the musl work, I'd guess?

Yeah, any way for us to follow along or get notified on progress of
the above would be appreciated.
--
Thanks,
~Nick Desaulniers

[Brian Cain]

> -----Original Message-----
> From: Nick Desaulniers <ndesau...@google.com>

> Sent: Thursday, April 29, 2021 2:46 PM
> To: Brian Cain <bc...@codeaurora.org>
> Cc: clang-built-linux <clang-bu...@googlegroups.com>;
> sid...@codeaurora.org; Manning, Sid <sid...@quicinc.com>
> Subject: Re: FW: ARCH=hexagon unsupported?
>

Unprivileged scalar core in QEMU is half-landed upstream, the remaining patch series due within ~weeks. Vector coproc is next, near term.

> Is the qemu work dependent on the musl work, I'd guess?

sysemu: no/kinda, hexagon-linux-user: yes. Initial testing for sysemu has been with a couple of linux alternatives: "standalone" (a hexagon-baremetal configuration w/angel calls) and the Qualcomm RTOS used on DSP targets and in the Qualcomm Hexagon SDK. Linux support is not as mature/robust yet, though we've seen it be able to come all the way up. Issues with the boot rom that linux uses are under investigation now.

> Yeah, any way for us to follow along or get notified on progress of the above
> would be appreciated.

For now: enable notifications on the https://github.com/quic/qemu/ repo. All of the activity so far is for userspace emulation. I've discussed publishing the sysemu work-in-progress as a branch of this quic/qemu repo, and I think it may still be gated by the arch specification being published. I'll re-raise this to see if we really have to do it in that order.

Also: I'll notify clang-built-linux when we make significant changes in the above.

-Brian

[Brian Cain]

Randy, thanks for your patience. We don't quite have all the kinks worked out for a release process but I have worked with the Linaro team to produce a clang-based cross toolchain and we can share a link:

https://codelinaro.jfrog.io/artifactory/codelinaro-qemu/2021-05-12/clang+llvm-12.0.0-cross-hexagon-unknown-linux-musl.tar.xz

Contents:
- clang+llvm+lld+libunwind+libcxx+libcxxabi built from `llvmorg-12.0.0` release
- `qemu-hexagon` binary (scalar core only!) built from upstream github.com/qemu/qemu repo `15106f7dc3290ff3254611f265849a314a93eb0e`
- headers from linux kernel 5.6.18
- C library built from github.com/quic/musl commit aff74b395fbf59cd7e93b3691905aa1af6c0778c
- unabridged build details in https://github.com/quic/qemu/tree/d26f3843c794d9d9b17b637550dc3b5a2bacd837/quic/container

Once we're able to produce releases on a more regular basis we should be able to share a hexagon-linux-user QEMU that can do scalar+vector. And some time after that a sysemu-capable qemu.

Our process for this first run did not include a signature for the build tarball, and that is regrettable. It will be included next time around. I have produced the sha256 signature below (post hoc) of the tarball that I tested:

55c51e8289cc21e6779cfc3b18bb9ad02632fc52d3c3a91bf6fdb4c8f578c84c clang+llvm-12.0.0-cross-hexagon-unknown-linux-musl.tar.xz

-Brian