From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A39BC171A9; Mon, 22 May 2023 20:01:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CF2A4C433D2; Mon, 22 May 2023 20:01:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1684785693; bh=q1rK3nNfauP5adtqxUDXHORtRgAnxyR+eJnFQ5R0jF0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=xcfIjk/fciRm77QI0VhJV5h9il1UvqFI/HD2zmYsMqBvEdZ9o386jiOAgRCvimVxV e4B10SMVELOUbdXuG6fGS7PGplTQ3l00pAdhvMx98gkHKSDRUDRGTDCyXQcs1KCqDk bt+fVqpvcQ18ZABu35kITdkahUv5XBIWntV2iNMw= Date: Mon, 22 May 2023 21:01:30 +0100 From: Greg KH To: Nick Desaulniers Cc: Maksim Panchenko , Ricardo =?iso-8859-1?Q?Ca=F1uelo?= , Shreeya Patel , Michal Marek , Masahiro Yamada , Linux Kernel Mailing List , clang-built-linux , Bill Wendling , Nathan Chancellor , regressions@lists.linux.dev, "gustavo.padovan@collabora.com" , Guillaume Charles Tucker , denys.f@collabora.com, kernelci@lists.linux.dev Subject: Re: [PATCH v4] Makefile.compiler: replace cc-ifversion with compiler-specific macros Message-ID: <2023052251-oncoming-glance-f1b0@gregkh> References: <878rdlk9bi.fsf@rcn-XPS-13-9305.i-did-not-set--mail-host-address--so-tickle-me> <875y8ok9b5.fsf@rcn-XPS-13-9305.i-did-not-set--mail-host-address--so-tickle-me> <87353ok78h.fsf@rcn-XPS-13-9305.i-did-not-set--mail-host-address--so-tickle-me> <2023052247-bobtail-factsheet-d104@gregkh> Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, May 22, 2023 at 12:52:13PM -0700, Nick Desaulniers wrote: > On Mon, May 22, 2023 at 9:52 AM Greg KH wrote: > > > > On Mon, May 22, 2023 at 12:09:34PM +0200, Ricardo Cañuelo wrote: > > > On vie, may 19 2023 at 08:57:24, Nick Desaulniers wrote: > > > > It could be; if the link order was changed, it's possible that this > > > > target may be hitting something along the lines of: > > > > https://isocpp.org/wiki/faq/ctors#static-init-order i.e. the "static > > > > initialization order fiasco" > > > > > > > > I'm struggling to think of how this appears in C codebases, but I > > > > swear years ago I had a discussion with GKH (maybe?) about this. I > > > > think I was playing with converting Kbuild to use Ninja rather than > > > > Make; the resulting kernel image wouldn't boot because I had modified > > > > the order the object files were linked in. If you were to randomly > > > > shuffle the object files in the kernel, I recall some hazard that may > > > > prevent boot. > > > > > > I thought that was specifically a C++ problem? But then again, the > > > kernel docs explicitly say that the ordering of obj-y goals in kbuild is > > > significant in some instances [1]: > > > > Yes, it matters, you can not change it. If you do, systems will break. > > It is the only way we have of properly ordering our init calls within > > the same "level". > > Ah, right it was the initcall ordering. Thanks for the reminder. > > (There's a joke in there similar to the use of regexes to solve a > problem resulting in two new problems; initcalls have levels for > ordering, but we still have (unexpressed) dependencies between calls > of the same level; brittle!). No, the dependencies are explicitly expressed with the linker order. So it's not brittle, but rather very deterministic. When linker order didn't work for all sorts of things, we added different levels, but due to the huge number of init calls, of course can not give each one their own level. It's always been this way with Linux, nothing new here at all :) thanks, greg k-h