From: Brian Cain <bcain@quicinc.com>
To: Rob Landley <rob@landley.net>,
Taylor Simpson <tsimpson@quicinc.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Sid Manning <sidneym@quicinc.com>
Cc: "ale@rev.ng" <ale@rev.ng>,
"peter.maydell@linaro.org" <peter.maydell@linaro.org>,
"richard.henderson@linaro.org" <richard.henderson@linaro.org>,
"philmd@redhat.com" <philmd@redhat.com>
Subject: RE: [PATCH 01/20] Hexagon HVX (target/hexagon) README
Date: Mon, 19 Jul 2021 13:39:35 +0000 [thread overview]
Message-ID: <BN7PR02MB4194007550E66EBE877625A6B8E19@BN7PR02MB4194.namprd02.prod.outlook.com> (raw)
In-Reply-To: <553c32e8-188c-5b2c-2f4a-a8cfd7b903a9@landley.net>
> -----Original Message-----
> From: Rob Landley <rob@landley.net>
...
> On 7/12/21 8:42 AM, Brian Cain wrote:
...
> > and there's also a binary hexagon-linux cross toolchain that
> > we shared for use by kernel developers. The hexagon linux
> > toolchain is built on Ubuntu 16.04.
>
> Where's that one?
https://codelinaro.jfrog.io/artifactory/codelinaro-qemu/2021-05-12/clang+llvm-12.0.0-cross-hexagon-unknown-linux-musl.tar.xz -
- Built on Ubuntu 16.04, similar dynamic dependencies as releases.llvm.org binaries
- Manifest:
- llvm+clang 12.0.0 tag
- Linux 5.6.18
- github.com/qemu/qemu 15106f7dc3290ff3254611f265849a314a93eb0e
- github.com/quic/musl aff74b395fbf59cd7e93b3691905aa1af6c0778c
> > But when building your toolchain, omitting LLVM_ENABLE_LLD should work
> just fine.
>
> It did, thanks.
>
> Now I'm trying to figure out what all the extra CFLAGS are for.
+Sid for some perspective on the rationale of these flags. Some of these flags may be workarounds for toolchain issues.
> The clang_rt build has CMAKE_ASM_FLAGS="-G0 -mlong-calls -fno-pic
> --target=hexagon-unknown-linux-musl" which
> https://clang.llvm.org/docs/ClangCommandLineReference.html defines as:
>
> -G<size>
> Put objects of at most <size> bytes into small data section (MIPS / Hexagon)
>
> -mlong-calls
> Generate branches with extended addressability, usually via indirect jumps.
>
> I don't understand why your libcc build needs no-pic? (Are we only building
> a static libgcc.a instead of a dynamic one? I'm fine with that if so, but
> this needs to be specified in the MAKE_ASM_FLAGS why?)
>
> Why is it saying --target=hexagon-random-nonsense-musl to a toolchain
> we built with exactly one target type? How does it NOT default to hexagon?
> (Is this related to the build writing a hexagon-potato-banana-musl.cfg file
> in the bin directory, meaning the config file is in the $PATH? Does clang only
> look for it in the same directory the clang executable lives in?)
>
> And while we're at it, the CONTENTS of hexagon-gratuitous-gnu-format.cfg is:
>
> cat <<EOF > hexagon-unknown-linux-musl.cfg
> -G0 --sysroot=${HEX_SYSROOT}
> EOF
>
> Which is ALREADY saying -G0? (Why does it want to do that globally? Some
> sort of
> bug workaround?) So why do we specify it again here?
>
> Next up build_musl_headers does CROSS_CFLAGS="-G0 -O0 -mv65 -fno-builtin
> -fno-rounding-math --target=hexagon-unknown-linux-musl" which:
>
> -O0
> disable most of the optimizer
>
> -mv65
> -mtune for a specific hexagon generation.
> (Why? Does qemu only support that but not newer?)
>
> -fno-builtin
> musl's ./configure already probes for this and will add it if
> the compiler supports it.
>
> -fno-rounding-math
> the docs MENTION this, but do not explain it.
>
> And again with the -G0.
>
> These flags probably aren't needed _here_ because this is just the headers
> install (which is basically a cp -a isn't it?). This looks like it's copied
> verbatim from the musl library build. But that library build happens in a bit,
> so relevant-ish I guess...
>
> (Also, why does building librt-but-not-really need the libc headers?
> The libgcc build EXPLICITLY does not require that, because otherwise you
> have this kind of BS circular dependency. Also, how do you EVER build a
> bare metal ELF toolchain with that dependency in there?)
>
> Next up build_kernel_headers has KBUILD_CFLAGS_KERNEL="-mlong-calls"
> which
> again, A) why does the compiler not do by default, B) can't be needed here
> because you don't even have to specify a cross compiler when doing
> headers_install. (I just confirmed this by diffing installs with an without a
> cross compiler specified: they were identical. I remembered this from
> https://github.com/torvalds/linux/commit/e0e2fa4b515c but checked again to
> be
> sure.) Presumably this is more "shared with full kernel build".
>
> And then build_musl, covered above under the headers build: lotsa flags, not
> sure why.
>
> > -Brian
> >
>
> Rob
>
> P.S. It took me a while to figure out that clang_rt is NOT librt.a, I think it's
> their libgcc? Especially confusing since librt.a has existed for decades and
> was on solaris before it was on linux, and the OBVIOUS name is libcc
> the same way "cc" is the generic compiler name instead of "gcc".
> (In fact that was the posix compiler name until they decided to replace
> it with "c99" and everybody ignored them the way tar->pax was ignored,
> largely because make's $CC defaults to "cc" so it Just Works, and yes
> the cross compiler should have that name but the prepackaged clang tarball
> above does not. *shrug* I fix that up when making my prefix symlinks. The
> android NDK guys at least have the excuse of shipping NINE different
> x86_64-linux-android*-clang with API version numbers and thus not wanting to
> pick a default to single out, so leave making the -cc link as an exercise for
> the reader. I give instructions for doing so on the toybox cross compiling page
> I linked above. :)
next prev parent reply other threads:[~2021-07-19 13:41 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-05 23:34 [PATCH 00/20] Hexagon HVX (target/hexagon) patch series Taylor Simpson
2021-07-05 23:34 ` [PATCH 01/20] Hexagon HVX (target/hexagon) README Taylor Simpson
2021-07-12 8:16 ` Rob Landley
2021-07-12 13:42 ` Brian Cain
2021-07-19 1:10 ` Rob Landley
2021-07-19 13:39 ` Brian Cain [this message]
2021-07-19 16:19 ` Sid Manning
2021-07-26 7:57 ` Rob Landley
2021-07-26 8:54 ` Rob Landley
2021-07-26 13:59 ` Taylor Simpson
2021-07-28 8:11 ` Rob Landley
2021-11-25 6:26 ` Rob Landley
2021-07-05 23:34 ` [PATCH 02/20] Hexagon HVX (target/hexagon) add Hexagon Vector eXtensions (HVX) to core Taylor Simpson
2021-07-25 13:08 ` Richard Henderson
2021-07-26 4:02 ` Taylor Simpson
2021-07-27 17:21 ` Taylor Simpson
2021-07-05 23:34 ` [PATCH 03/20] Hexagon HVX (target/hexagon) register names Taylor Simpson
2021-07-25 13:10 ` Richard Henderson
2021-07-05 23:34 ` [PATCH 04/20] Hexagon HVX (target/hexagon) support in gdbstub Taylor Simpson
2021-07-05 23:34 ` [PATCH 05/20] Hexagon HVX (target/hexagon) instruction attributes Taylor Simpson
2021-07-05 23:34 ` [PATCH 06/20] Hexagon HVX (target/hexagon) macros Taylor Simpson
2021-07-25 13:13 ` Richard Henderson
2021-07-05 23:34 ` [PATCH 07/20] Hexagon HVX (target/hexagon) import macro definitions Taylor Simpson
2021-07-05 23:34 ` [PATCH 08/20] Hexagon HVX (target/hexagon) semantics generator Taylor Simpson
2021-07-05 23:34 ` [PATCH 09/20] Hexagon HVX (target/hexagon) semantics generator - part 2 Taylor Simpson
2021-07-05 23:34 ` [PATCH 10/20] Hexagon HVX (target/hexagon) C preprocessor for decode tree Taylor Simpson
2021-07-25 13:15 ` Richard Henderson
2021-07-05 23:34 ` [PATCH 11/20] Hexagon HVX (target/hexagon) instruction utility functions Taylor Simpson
2021-07-25 13:21 ` Richard Henderson
2021-07-05 23:34 ` [PATCH 12/20] Hexagon HVX (target/hexagon) helper functions Taylor Simpson
2021-07-25 13:22 ` Richard Henderson
2021-07-26 4:02 ` Taylor Simpson
2021-07-05 23:34 ` [PATCH 13/20] Hexagon HVX (target/hexagon) TCG generation Taylor Simpson
2021-07-05 23:34 ` [PATCH 14/20] Hexagon HVX (target/hexagon) import semantics Taylor Simpson
2021-07-05 23:34 ` [PATCH 15/20] Hexagon HVX (target/hexagon) instruction decoding Taylor Simpson
2021-07-05 23:34 ` [PATCH 16/20] Hexagon HVX (target/hexagon) import instruction encodings Taylor Simpson
2021-07-05 23:34 ` [PATCH 17/20] Hexagon HVX (tests/tcg/hexagon) vector_add_int test Taylor Simpson
2021-07-05 23:34 ` [PATCH 18/20] Hexagon HVX (tests/tcg/hexagon) hvx_misc test Taylor Simpson
2021-07-05 23:34 ` [PATCH 19/20] Hexagon HVX (tests/tcg/hexagon) scatter_gather test Taylor Simpson
2021-07-05 23:34 ` [PATCH 20/20] Hexagon HVX (tests/tcg/hexagon) histogram test Taylor Simpson
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=BN7PR02MB4194007550E66EBE877625A6B8E19@BN7PR02MB4194.namprd02.prod.outlook.com \
--to=bcain@quicinc.com \
--cc=ale@rev.ng \
--cc=peter.maydell@linaro.org \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=rob@landley.net \
--cc=sidneym@quicinc.com \
--cc=tsimpson@quicinc.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).