[llvmlinux] Clang/LLVM for ARM rebase to 4.13

[Stefan Agner]

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.

> 
>> 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.

> 
> 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/

> 
> 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...

> 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.

> 
> 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.

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.

--
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