Old Compilers and Old Bugs | Hacker News Reader

Old Compilers and Old Bugs

lwn.net

81 pointsTomte15 comments

> RHEL 7 (and thus CentOS 7) systems are still stuck with GCC 4.8 [..] other known users of GCC 4.9 were Android and Debian 8

Is this really a practical problem? I don't have the impression that compiling the latest kernel is a common use case on CentOS, as CentOS users want very boring very old software, which is kind of the point of the entire system. But maybe people are doing it regardless?

I guess it is mostly a problem for RedHat: The RH kernel is nominally an old stable version, but with fixes and hardware support frankensteined on from the later to latest kernel versions. If new kernel versions now start to expect features and behaviour of newer compiler versions, those backports become more difficult.

> Is this really a practical problem?

Oh, yes. There are many industrial settings in which toolchains are set for systems provided to customers, and those systems don't get a full software revamp for a decade if not much more than that.

Yeah, I worked in a few settings like this; but in those cases (very) old "LTS" kernel versions were used as well, so in my (limited) experience very old toolchains tends to be tied to very old, well, everything (including kernel).

RHEL and CentOS 7 are using kernel 3.10.x even in 7.9 OS versions. That is, that's the nominal version that's distributed by the system and has all sorts of backported patches, especially but not exclusively for bugs with CVEs. For example, 3.10.0-1160.11.1.el7 is relatively recent, being updated 30 November 2020.

Yeah, it's possible to download any version of the kernel sources and build it, but the chances of having a system that boots into a 5.x.x kernel under RHEL or CentOS is pretty small.

What a nasty bug! I would never have guessed that the order of stack-pointer arithmetic and operations on stack variables mattered. I wonder how much of the generated code must be "pessimized" to be interrupt-safe. This could be an actual pessimization if a section of code is only executed with interrupts turned off (I don't know if this happens within the kernel).

How does this relate to user-space code? Could the same bug manifest is user-space code when handling signals? I don't know much about how exactly signals are delivered and handled in user-space processes.

edit: Now that I think about it red zone in user-space pretty much assumes that the equivalent can't happen there. It appears that red zone is disabled for the kernel precisely because of interrupts. I still wonder how signal handlers interact with the user-space thread's stack.

Signal handlers have their own stack for this very reason.

Handling interrupts within the Linux kernel is not really very similar to signal handling in userspace.

From the very little research I did signal handlers actually use the same stack as the user-space thread it runs on, unless sigaltstack is used to set up a separate stack. Although it's probably possible for the kernel to adjust the stack pointer over the red-zone before returning to user-space, so the signal handler can run safely.

By default signal handlers don't use a separate stack; they use the same stack as the process/thread that received the signal. A process/thread must call sigaltstack to install an alternative stack for signal handler execution.

So to answer the previous poster's question: yes, AFAICT this bug could have effected userspace code unless there are some other nuances at play.

> Currently, kernel builds use -std=gnu89, based on the rather less shiny C89 standard. Zijlstra and Deacon both added that moving to 5.1 would allow the removal of a number of workarounds for GCC 4.9 problems.

Why isn't the Linux kernel compiled with `-std=gnu99`? That's been supported in GCC since well before 4.9.

> Fixing GCC 4.9 to address this bug is out of the question; the GCC developers have long since moved on from that release.

I really don't understand why that is. 4.9.x is the last release branch in the 4 series, so it's not as though there is another 4-series branch to maintain. And 4.9.0 came out in 2014. I don't see why it is out of the question to release 4.9.5 - with the patch already having been backported to 4.9.4 by others; and the fact that there's no change in library API, command-line arguments etc.

Now, perhaps it is the case that GCC doesn't have enough manpower to support releases for 6 years. But doing so can't just be dismissed as "out of the question".

Compilers are very fundamental pieces of software - perhaps no less than OS kernels - and they shouldn't just be "moved on" from.

If there was "just one bug", that might be possible, but there are probably dozens or even hundreds of bugs fixed in newer versions of GCC which effect 4.9.x. Someone would have to figure out which bugs are in 4.9.x, backport the patches (which could be hard if significant changes have occurred).

As you say, it could in principle be done, but GCC doesn't have a huge amount of funding (most companies support LLVM/clang if they support any compiler, which to be honest makes a lot of sense, they are much more business-friendly)

I don't think that developers in general have great interest in maintaining obsolete code which would only cause some users to continue using that old code, perpetuating the maintenance headache. Money buys you that interest, but in the free software world you better move along with the developers.

> I don't think that developers in general have great interest in maintaining obsolete code which would only cause some users to continue using that old code, perpetuating the maintenance headache.

Well, you know, if you're in a project central to a lot of the FOSS world, then there's a mix of doing exciting new features and doing maintenance. Plus, if you just think of "fixing a compiler bug" as "fixing it on the N versions we're currently supporting", it may feel as less of a pain than "backporting a bunch of bug fixes".

> Money buys you that interest, but in the free software world you better move along with the developers.

Hey, I'm in the free software world. I maintained a Seamonkey 1.x version of an extension of mine until last year - 13 years after the last significant release (1.1).

I bet the developer who made the commit that triggered this wasn't expecting it would have such an effect.

Reply on news.ycombinator.com