[Bug 1843394]

[Hjl-tools]

It is caused by

commit 21df382b918888de64749e977f185c4e10a5b838
Author: Jan Beulich <jbeulich at suse.com>
Date:   Tue Jul 16 09:30:29 2019 +0200

    x86: fold SReg{2,3}
    
    They're the only exception to there generally being no mix of register
    kinds possible in an insn operand template, and there being two bits per
    operand for their representation is also quite wasteful, considering the
    low number of uses.  Fold both bits and deal with the little bit of
    fallout.
    
    Also take the liberty and drop dead code trying to set REX_B: No segment
    register has RegRex set on it.
    
    Additionally I was quite surprised that PUSH/POP with the permitted
    segment registers is not covered by the test cases.  Add the missing
    pieces.

Assembler disallows "popq %fs", but disassembler still display "popq
%fs".

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843394

Title:
  FTBFS in Eoan - Error: operand type mismatch for `push' - gcc 9.2.1 /
  binutils 2.32.51.20190905-0ubuntu1

Status in binutils:
  Confirmed
Status in binutils package in Ubuntu:
  New
Status in ipxe package in Ubuntu:
  New

Bug description:
  This might be due to new gcc-9 being more strict, but the build that
  worked before now fails with:

  arch/x86_64/core/gdbidt.S: Assembler messages:
  arch/x86_64/core/gdbidt.S:109: Error: operand type mismatch for `push'
  arch/x86_64/core/gdbidt.S:110: Error: operand type mismatch for `push'
  arch/x86_64/core/gdbidt.S:161: Error: operand type mismatch for `pop'
  arch/x86_64/core/gdbidt.S:162: Error: operand type mismatch for `pop'
  make[2]: *** [Makefile.housekeeping:937: bin-x86_64-efi/gdbidt.o] Error 1

  Full log at: https://launchpadlibrarian.net/441262285/buildlog_ubuntu-
  eoan-amd64.ipxe_1.0.0+git-20190109.133f4c4-0ubuntu2_BUILDING.txt.gz

  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/x86_64/core/gdbidt.S
  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://codesearch.debian.net/search?q=pop%5Ba-z%5D.*%25fs&literal=0&page=2

  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-frame-pointer -falign-jumps=1 -falign-loops=1 -falign-functions=1 -m64 -mno-mmx -mno-sse -fshort-wchar -Ui386 -Ulinux -DNVALGRIND -fpie -mno-red-zone -Iinclude -I. -Iarch/x86/include -Iarch/x86_64/include -Iarch/x86_64/include/efi -Os -g -ffreestanding -Wall -W -Wformat-nonliteral  -fno-stack-protector -fno-dwarf2-cfi-asm -fno-exceptions  -fno-unwind-tables -fno-asynchronous-unwind-tables -Wno-address -Wno-stringop-truncation   -ffunction-sections -fdata-sections -include include/compiler.h -DASM_TCHAR='@' -DASM_TCHAR_OPS='@' -DASSEMBLY  -DOBJECT=gdbidt arch/x86_64/core/gdbidt.S | as  --64    -o bin-x86_64-efi/gdbidt.o

To manage notifications about this bug go to:
https://bugs.launchpad.net/binutils/+bug/1843394/+subscriptions