gcc ignores large _Alignas specifiers on static .bss data
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
gcc-defaults (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
Instructions to reproduce: compile the following C program:
```
#include <stdio.h>
static _Alignas(4 << 20) int x;
int main(void) {
printf(
return 0;
}
```
using `gcc` with no arguments other than the program's filename (which must end `.c` so that gcc interprets it as a C program), and run the resulting a.out.
Expected behaviour: the program prints a number that's divisible by 2²² (in hexadecimal, the resulting number will end with five zeroes, and the preceding digit will be divisible by 4).
Actual behaviour: the program prints an arbitrary number that's divisible by 2¹², but which is normally not divisible by 2²². (The exact number varies between runs of the program; some example observed values include 0x55c2be889000 and 0x55d2cd348000.)
This bug seems to be somehow specific to the way Ubuntu has configured `gcc` – it doesn't show up on a Red Hat-based Linux system, or when compiling using `clang`. As far as I can tell, the bug isn't in the compiler portion of `gcc`, but rather in the driver process; something in the arguments that it's passing to the linker is causing this behaviour.
I suspect that the bug is related to position independent code. (In particular, compiling with `gcc -fno-pie` will cause an error along the line of `/usr/bin/ld: /tmp/cc6nztmN.o: relocation R_X86_64_32 against `.bss' can not be used when making a PIE object; recompile with -fPIE`, rather than linking successfully, which means that the linker has been told by the compiler to make a position-
It is possible that this misbehaviour has been introduced intentionally for security reasons (because requiring a large alignment for the program image reduces the amount of security that address space layout randomization can provide). However, in this case, I think the correct behaviour should be to reject the program with an error, rather than apparently compiling it successfully, but producing a program that gives incorrect results at runtime.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: gcc 4:9.3.0-1ubuntu2
ProcVersionSign
Uname: Linux 5.4.0-91-generic x86_64
ApportVersion: 2.20.11-
Architecture: amd64
CasperMD5CheckR
CurrentDesktop: X-Cinnamon
Date: Sun Dec 12 17:01:45 2021
InstallationDate: Installed on 2019-11-11 (761 days ago)
InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 (20190805)
SourcePackage: gcc-defaults
UpgradeStatus: Upgraded to focal on 2020-10-02 (436 days ago)