[llvmlinux] Clang/LLVM for ARM rebase to 4.13

Sedat Dilek sedat.dilek at gmail.com
Thu Aug 10 15:09:14 UTC 2017

On Mon, Aug 7, 2017 at 7:18 PM, Stefan Agner <stefan at agner.ch> wrote:
> On 2017-08-07 02:35, Sedat Dilek wrote:
>> On Mon, Aug 7, 2017 at 9:17 AM, Stefan Agner <stefan at agner.ch> wrote:
>>> Hi,
>>> Fwiw, I rebased the Clang/LLVM patches required to build 32-bit ARM
>>> kernels to v4.13-rc4:
>>> http://git.agner.ch/gitweb/?p=linux.git;a=shortlog;h=refs/heads/armv7-master-clang-v4.13-rc4
>> Hi Stefan,
>> thanks for your feedback!
>> Do you happen to know (or have tested) the combination of Linux
>> v4.13-rc4 with x86_64 with your Git tree?
> I did not...
>>> I also run kernels built with Clang/LLVM 4.0.1 successfully (again,
>>> after I had issues with 4.0.0).
>> Did you try other versions of Clang (example: 3.9.x)?
>> Is this a self-compiled llvm-toolchain, prebuilt-toolchain (from
>> Linaro?) or offered by your $distro?
> I use the version provided by Arch Linux. Since 4.0.1 works now, I did
> not saw the need to test older versions. With 4.11 I did use 3.9 series.

I have my llvm-toolchain-3.9.x stuff on my old Ubuntu 12.04 system.
It's EOL, so.

>>> The patch count dropped significantly since several Kbuild patches got
>>> merged recently.
>> Great to hear there is progress (to see patches I had in my own queue
>> are now in upstream [3]).
>> My personal opinion on llvmlinux (Clang): It is very helpful to make a
>> lot of warnings and errors visible.
>> Not happy why kbuild-patches which require a "cc-XXX" call are not
>> used by default (example see [1]).
>> Desired is a meachnism which handles this automagically, means check
>> if $compiler really supports $compiler-flag.
>> [4] is no more supported with recent Clang versions?
>> Embed in a cc-XXX-call instead?
> I think it never was, but not sure about that.
> Since this flags are explicitly added for clang, no need for a cc-option
> call. Also, this is HOSTCFLAGS, cc-option is for target.

Yeah, you are right here.

>> Is your ext4-fix still necessary or fixed by [2] in upstream?
> No, that commit actually broke it. Arnd sent a fix, see:
> https://patchwork.kernel.org/patch/9885007/

i don't see Ted CCed on this patch and in none of his Git-trees.

>> Looking at the list of [0] there are some more people doing good work
>> on getting stuff fixed with Clang.
>> What about the idea of co-working?
> Sure, we all collaborate on this...

Somehow - for years - with known issues (very old ones)
I personally think Linux-4.13 is really in a good shape for further
testings - 4.9.y-LTS needs a lot of cherry-picks.
As said I did my testings on a Ubuntu 12.04 box which require a lot of
self-compiled stuff like a higher version of gcc and binutils, etc.
With the release of Debian/stretch I have a 2nd system which is very virgin.
Cannot promise to do a check of current state of getting it build and
run on my notebook.

>> I have asked this a lot ob this mailing-list (I ask again):
>> What about an agreed development base using stable (released) versions
>> of llvm-toolchain, Linux-kernel (preferably LTS) release and
>> build-tools (binutils, llvm-$tools like assembler, linker, etc.).
>> It's a bit useless for me of not knowing how to reproduce ((re)build)
>> with your tree.
>> Example: You forgot to attach your kernel-config file, for me this is
>> indispensable.
> I tested only ARM, a config for my target (i.MX 7) and allmodconfig with
> some minor modification (e.g. it enabled big endian in my case.

I know of broken linux-configs for x86-64, that might be changed.
I have a minimal linux-config which boots on bare metal.

>> Last but least, what is the plan to get some of your (for me obvious!)
>> patches upstream?
>> To keep tons of patches downstream is not very wise.
>> (If you have no "plan a" or "plan b" the alphabet has 24 more letters :-).)
> I already posted some of the changes to the ML.

Which ML do you mean? llvmlinux and/or linux-kernel ML?

> As far as I can tell, the build system is now pretty much ready for
> clang upstream. Most of the kernel compiles just fine, there are a few
> build breakages here and there, but for most of them patches are already
> on the ML.
> There are some architecture specific patches missing, at least for ARM.
> But these patches definitely need more work in order to be accepted,
> they also likely break other use cases. I was thinking about working on
> them myself, but haven't had the time yet.

I should switch over to ARM arch, eh ;-)?
No, x86 is my world, right now.

- sed@ -

> --
> Stefan
>> Looking forward reading from you!
>> Regards,
>> - Sedat -
>> [0]
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=clang
>> [1]
>> http://git.agner.ch/gitweb/?p=linux.git;a=commitdiff;h=4abb412be4937662495c027e9ee47089ad60395c
>> [2]
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2df2c3402fc81918a888e1ec711369f6014471f2
>> [3]
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4a1bec4605838fd7872ec41677585e241e256785
>> [4]
>> http://git.agner.ch/gitweb/?p=linux.git;a=commitdiff;h=929b85c7afe1536c6d56b5b699c9fb264113ba38

More information about the LLVMLinux mailing list