From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) (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 DD6A9A94C; Mon, 22 May 2023 10:09:45 +0000 (UTC) Received: from localhost (unknown [IPv6:2a0c:5a83:9203:ad00:c068:e703:1301:7049]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: rcn) by madras.collabora.co.uk (Postfix) with ESMTPSA id 96EB36605706; Mon, 22 May 2023 11:09:37 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1684750177; bh=6rimz3xbCtOIAsgtzqTRf5vqJmiKmuivxmZtfJtFqCI=; h=From:To:Cc:Subject:References:In-reply-to:Date:From; b=BSK1xoZm/IlfL0P2CI3I3YbJsUU8lZSAIrGKGgUQiJ7odBhMH22zguUC+xNsHcdVO 2LCJXoaTEATkpK/ZlNsSisuMThoQdIRp75V85qbkBbXcH5EpULVkY0z6L5vfP4q3rZ LOGRmm+cAQUZFNyeaFkKHi1ANHYn7dF7tscSTYc1hMFgYCwUadXkmfkbrsKMkQdDhU MQrjFsEKl60dR9U0IGPkc4HCUtRhMtSwp4rs7R676LQc7nY2ZahVmAdNmfR/xBuuW8 rIowwyVVqaBa4c/ha/RZaffma63e7jl6O1PTm0uj4o3Yp7Z6Mx4iXmOWrwqyZAsUIS RLihHMT+ezdOg== From: Ricardo =?utf-8?Q?Ca=C3=B1uelo?= To: Nick Desaulniers Cc: 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, Greg KH Subject: Re: [PATCH v4] Makefile.compiler: replace cc-ifversion with compiler-specific macros References: <20220919170828.3718437-1-ndesaulniers@google.com> <597ef55f-e7c1-ab60-b4aa-0071ff4b5e0e@collabora.com> <89961dfc-d40f-78e4-5d34-b86b7d152182@collabora.com> <17c91d37-7d9c-0df4-2438-2b30ca0b5777@collabora.com> <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> In-reply-to: Date: Mon, 22 May 2023 12:09:34 +0200 Message-ID: <87353ok78h.fsf@rcn-XPS-13-9305.i-did-not-set--mail-host-address--so-tickle-me> Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain 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]: --- 3.2 Built-in object goals - obj-y [...] Link order is significant, because certain functions (module_init() / __initcall) will be called during boot in the order they appear. So keep in mind that changing the link order may e.g. change the order in which your SCSI controllers are detected, and thus your disks are renumbered. We'll dig deeper into this. Thanks for your insight. Cheers, Ricardo [1]: https://www.kernel.org/doc/Documentation/kbuild/makefiles.txt