From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 216D9C433FE for ; Sat, 4 Sep 2021 13:23:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 013486108E for ; Sat, 4 Sep 2021 13:23:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233844AbhIDNYg (ORCPT ); Sat, 4 Sep 2021 09:24:36 -0400 Received: from gate.crashing.org ([63.228.1.57]:51486 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233703AbhIDNYg (ORCPT ); Sat, 4 Sep 2021 09:24:36 -0400 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 184DJCVJ031110; Sat, 4 Sep 2021 08:19:12 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 184DJBeH031102; Sat, 4 Sep 2021 08:19:11 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Sat, 4 Sep 2021 08:19:11 -0500 From: Segher Boessenkool To: Florian Weimer Cc: Nathan Chancellor , Linus Torvalds , Masahiro Yamada , Nick Desaulniers , Linux Kbuild mailing list , Linux Kernel Mailing List , clang-built-linux , llvm@lists.linux.dev, linux-toolchains@vger.kernel.org Subject: Re: [GIT PULL v2] Kbuild updates for v5.15-rc1 Message-ID: <20210904131911.GP1583@gate.crashing.org> References: <3b461878-a4a0-2f84-e177-9daf8fe285e7@kernel.org> <878s0c4vng.fsf@oldenburg.str.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <878s0c4vng.fsf@oldenburg.str.redhat.com> User-Agent: Mutt/1.4.2.3i Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Sat, Sep 04, 2021 at 10:01:07AM +0200, Florian Weimer wrote: > * Nathan Chancellor: > > We set up the linux-toolchains mailing list after Plumbers 2020 to > > have a common place that kernel developers can bring issues and > > discussion to both clang and GCC folks. I am not sure who exactly from > > the GCC world is subscribed but I have added it now to see. > > Someone said that they “agree with the reasoning”, but the original > patch does not provide one. It looks like it's about preventing the use > of compiler-supplied header files, but even that doesn't really answer > the question: why? > > Especially since some parts of the kernel actually need some of those > header files. Let me quote the original mail (I had to dig it out of the archives as well, no nice threading, too lazy, sorry): > On Thu, Sep 2, 2021 at 4:31 PM Masahiro Yamada wrote: > > > > I fixed the warnings observed in the previous PR. > > Ok, let's try it again. > > > - Add to the kernel source instead of borrowing > > from the compiler. > > So I certainly agree with the reasoning, but this worries me a bit. > > stdarg is truly intimately an internal compiler file, in ways that > stddef (to pick another example) isn't. > > Yeah, yeah, offsetof() is "kind of compiler internal", and we end up > using __compiler_offsetof(), but in the absence of that we *can* just > do it by hand. So offsetof() really is one of those things where we > can just do our own version if some compiler is being difficult. > > But va_start and friends absolutely *must* match the exact compiler version. > > It does look like both gcc and clang have just standardized on using > __builtin_xyz for all the different stdarg things, and so I approve of > what that ended up looking like. > > But at the same time, it does make me go "ok, this is a big new > assumption that we've consciously avoided for a long time". > > Nick is already on the cc here for other reasons, but let's add the > clang-built list and Nathan explicitly. Because this basically > codifies that > > typedef __builtin_va_list va_list; > #define va_start(v, l) __builtin_va_start(v, l) > #define va_end(v) __builtin_va_end(v) > #define va_arg(v, T) __builtin_va_arg(v, T) > #define va_copy(d, s) __builtin_va_copy(d, s) > > being the way all the supported compilers work. > > Did people talk to any gcc maintainers too? We don't have the same > kind of "gcc kernel people" list or contacts. The above builtins have > been the case for a long long time for gcc, so I don't think it's > wrong or likely to change, but I think it would be a good thing to > just make compiler people aware of how we're now relying on that > explicitly. > > (Side note: Linux using the compiler goes so far back that > it very much predates all those nice builtins. I still have memories > of being a collection of nasty per-architecture messes back > in the bad old days. So I'm actually happy we can do this now, but > there most definitely was a time when we really really had to use the > compiler-provided stdarg.h). > > Linus is a header that any C implementation is required to provide to give some certain functionality (one type and four macros, in this case, mentioned above). No implementation is allowed to put anything in those headers that can conflict with anything in user code or in some implementation's internals, and I haven't heard of any implementation breaking in that way for decades, there is absolutely no reason not to use . It is one of the few headers required from freestanding implementations even (and is another for that matter: the full list is , , , , , , , , and ). I recommend using this. It is what it is for. It works in all compilers. Not using it is not writing in C. Segher