On Tue, Jan 26, 2021 at 11:07 AM Greg KH <greg@xxxxxxxxx> wrote: > > On Tue, Jan 26, 2021 at 10:19:34AM -0600, Josh Poimboeuf wrote: > > On Tue, Jan 26, 2021 at 10:15:52AM -0600, Justin Forbes wrote: > > > On Tue, Jan 26, 2021 at 10:05 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > > > > > > > On Tue, Jan 26, 2021 at 09:46:51AM -0600, Josh Poimboeuf wrote: > > > > > On Tue, Jan 26, 2021 at 04:15:37PM +0100, Peter Zijlstra wrote: > > > > > > On Tue, Jan 26, 2021 at 08:51:55AM -0600, Josh Poimboeuf wrote: > > > > > > > User space mixes compiler versions all the time. The C ABI is stable. > > > > > > > > > > > > > > What specifically is the harder issue you're referring to? > > > > > > > > > > > > I don't think the C ABI captures nearly enough. Imagine trying to mix a > > > > > > compiler with and without asm-goto support (ok, we fail to build without > > > > > > by now, but just imagine). > > > > > > > > > > > > No C ABI violated, but having that GCC extention vs not having it > > > > > > radically changes the kernel ABI. > > > > > > > > > > > > I think I'm with Greg here, just don't do it. > > > > > > > > > > Ok, thank you for an actual example. asm goto is a good one. > > > > > > > > > > But it's not a cut-and-dry issue. Otherwise how could modversions > > > > > possibly work? > > > > > > > > > > So yes, we should enforce GCC versions, but I still haven't seen a > > > > > reason it should be more than just "same compiler and *major* version". > > > > > > > > Why bother? rebuilding the kernel and all modules is a matter of 10 > > > > minutes at most on a decently beefy build box. > > > > > > > > What actual problem are we trying to solve here? > > > > > > This is true for those of us used to working with source and building > > > by hand. For users who want everything packaged, rebuilding a kernel > > > package for install is considerably longer, and for distros providing > > > builds for multiple arches, we are looking at a couple of hours at > > > best. From a Fedora standpoint, I am perfectly fine with it failing > > > if someone tries to build a module on gcc10 when the kernel was built > > > with gcc11. It's tedious when the kernel was built with gcc11 > > > yesterday, and a new gcc11 build today means that kernel needs to be > > > rebuilt. > > > > Right. It's a problem for distro users. The compiler and kernel are in > > separate packages, with separate release cadences. The latest compiler > > version may not exactly match what was used to build the latest kernel. > > Given that distros _should_ be updating their kernel faster than the > compiler updates, what's the real issue here? You build a kernel, and > all external modules, at the same time. If you want to build them at > different times, you make your build system ensure they were the same > compiler so that you are "bug compatible". > > And yes, it might be a pain if gcc11 gets updated every other day, but > as someone living with a "rolling-distro" you get used to it, otherwise > you just "pin" the build tools and keep that from happening. > > This isn't a new thing, we've been doing this for decades, why is this > surprising? We definitely build considerably more kernels than toolchains. From a rawhide standpoint though, a number of testers are willing to test RC releases, but are not willing to run debug kernels, so they installed rc4 yesterday, but will not install today's snapshot. I will build 3-5 new kernels before they update to rc5. We have been doing things this way for over a decade. It has never been a problem until we turned on CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL. Suddenly I am getting complaints.
