[llvmlinux] Clang/LLVM for ARM rebase to 4.13
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:
>>> Fwiw, I rebased the Clang/LLVM patches required to build 32-bit ARM
>>> kernels to 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 ).
>> 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 ).
>> Desired is a meachnism which handles this automagically, means check
>> if $compiler really supports $compiler-flag.
>>  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  in upstream?
> No, that commit actually broke it. Arnd sent a fix, see:
i don't see Ted CCed on this patch and in none of his Git-trees.
>> Looking at the list of  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
> 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@ -
>> Looking forward reading from you!
>> - Sedat -
More information about the LLVMLinux