lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230324151150.GC428955@dev-arch.thelio-3990X>
Date:   Fri, 24 Mar 2023 08:11:50 -0700
From:   Nathan Chancellor <nathan@...nel.org>
To:     Kalle Valo <kvalo@...nel.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        dri-devel@...ts.freedesktop.org, linux-toolchains@...r.kernel.org,
        llvm@...ts.linux.dev
Subject: Re: Linux 6.3-rc3

On Fri, Mar 24, 2023 at 12:54:01PM +0200, Kalle Valo wrote:
> Nathan Chancellor <nathan@...nel.org> writes:
> 
> > On Wed, Mar 22, 2023 at 02:44:47PM +0200, Kalle Valo wrote:
> >> Nathan Chancellor <nathan@...nel.org> writes:
> >> 
> >> > Perhaps these would make doing allmodconfig builds with clang more
> >> > frequently less painful for you?
> >> >
> >> > https://lore.kernel.org/llvm/20230319235619.GA18547@dev-arch.thelio-3990X/
> >> 
> >> Thank you, at least for me this is really helpful.
> >
> > Really glad to hear! I hope this helps make testing and verifying
> > changes with clang and LLVM easier for developers and maintainers.
> 
> It really does. And I hope you are able to update these packages in
> future as well so that it would be easy to get the latest clang.

That is the current plan (I will push 16.0.1, 16.0.2, etc. as they are
released), I have a relatively automated process for this going forward.

> >> I tried now clang for the first time but seeing a strange problem.
> >> 
> >> I prefer to define the compiler in GNUmakefile so it's easy to change
> >> compilers and I don't need to remember the exact command line. So I have
> >> this in the top level GNUmakefile (all the rest commented out):
> >> 
> >> LLVM=/opt/clang/llvm-16.0.0/bin/
> >> 
> >> If I run 'make oldconfig' it seems to use clang but after I run just
> >> 'make' it seems to switch back to the host GCC compiler and ask for GCC
> >> specific config questions again. Workaround for this seems to be adding
> >> 'export LLVM' to GNUmakefile, after that also 'make' uses clang as
> >> expected.
> >
> > Interesting... I just tested with a basic GNUmakefile and everything
> > seems to work fine without an export. At the same time, the export
> > should not hurt anything, so as long as it works, that is what matters.
> 
> Sure, once I figured out the quirks I can workaround them. I was just
> hoping that other users would not have to go through the same hassle as
> I did :)
> 
> > If you have any further issues, please do not hesitate to reach out!
> 
> This is nitpicking but it would be nice if the tarball contents wouldn't
> conflict with each other. Now both llvm-16.0.0-aarch64.tar.gz and
> llvm-16.0.0-x86_64.tar extract to the same directory llvm-16.0.0 with
> same binary names. It would be much better if they would extract to
> llvm-16.0.0-aarch64 and llvm-16.0.0-x86_64, respectively.
> 
> For example, Arnd's crosstool packages don't conflict with each other:
> 
> https://mirrors.edge.kernel.org/pub/tools/crosstool/

I could certainly do that but what is the use case for extracting both?
You cannot run the aarch64 version on an x86_64 host and vice versa, so
why bother extracting them? I had figured the architecture would be
irrelevant once installed on the host, so I opted only to include it in
the tarball name. Perhaps I should make it clearer that these are the
host architectures, not the target architectures (because clang is
multi-targeted, unlike GCC)?

> And maybe request a similar llvm directory under pub/tools to make it
> more official? :)

Yes, I was talking that over with Nick recently, as having it under a
group on kernel.org would make taking over maintainership easier should
something happen to me :)

Thanks for all the feedback so far, it is much appreciated!

Cheers,
Nathan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ