FTBFS in Eoan - Error: operand type mismatch for `push' - gcc 9.2.1 / binutils 2.32.51.20190905-0ubuntu1
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
binutils |
Fix Released
|
Medium
|
|||
binutils (Ubuntu) |
Fix Released
|
Critical
|
Matthias Klose | ||
ipxe (Ubuntu) |
Invalid
|
High
|
Unassigned |
Bug Description
This might be due to new gcc-9 being more strict, but the build that worked before now fails with:
arch/x86_
arch/x86_
arch/x86_
arch/x86_
arch/x86_
make[2]: *** [Makefile.
Now all of this is about push/pop of %fs and %gs.
That needs to match the size of the registers which depend on the current running mode.
In this particular case in ./src/arch/
The failing file is in ".code64" mode.
In that I'd expect %gs/%fs to be 64 bit.
Usually we see push/pop "w" in .code16 (word), l in .code32 (long) but in that sense here q (quad word) seems right at first (should be what correctly matches the .code64).
That matches what I see throughout the ipxe code but also throughout the archive https:/
Maybe I misread the mode it is in, or it is actually a false positives.
Or the sizes of FS/GS do not change - haven't touched them in a loooong time.
Was it that segment registers didn't change size?
I'll need to do a few checks to first see what the compiler would expect there and from there need to understand this.
The command used also points to AS being in 64 bit mode when this happens:
gcc -E -DARCH=x86_64 -DPLATFORM=efi -DSECUREBOOT=0 -fstrength-reduce -fomit-
Related branches
- Andreas Hasenack: Pending requested
- Canonical Server: Pending requested
- git-ubuntu developers: Pending requested
-
Diff: 136 lines (+108/-0)4 files modifieddebian/changelog (+9/-0)
debian/patches/FTFBS-gcc9.patch (+38/-0)
debian/patches/lp-1843394-compilation-error-with-gcc-9.1.patch (+59/-0)
debian/patches/series (+2/-0)
tags: | added: ftbfs |
Changed in binutils: | |
importance: | Unknown → Medium |
status: | Unknown → New |
Changed in binutils: | |
status: | New → Confirmed |
Changed in ipxe (Ubuntu): | |
status: | New → Triaged |
importance: | Undecided → High |
tags: | added: server-next |
Changed in ipxe (Ubuntu): | |
assignee: | nobody → Christian Ehrhardt (paelzer) |
Changed in binutils: | |
status: | Confirmed → Fix Released |
I have an experimental fix, but I sort of do not trust it yet as I struggle to recreate the same issue with a build from git. But the failing code still is the same.
So I want to check if there as a (very different) way committed upstream to fix this.