Summary D vs E:
- no suffix
  => works equally in both releases
  => same opcodes in all .code segments
- suffix "w"
  => works equally in both releases
  => opcodes in .code32/.code64 differ from .code16 (660f..)
  => .code16 matches the non-suffix opcodes (0f..)
- suffix "l"
  => failures in Disco, works in Eoan
  => .code16 opcodes match the non-.code16 of the "w" suffix (660f..)
  => .code32/.code64 are back to the base opcode (0f..)
  => If I remove the failing .code64 from disco then .code16/.code32 is the 
same as in Eoan
- suffix "q"
  => different failures in Disco and Eoan
  => in Disco .code16/.code32 fails
  => in Disco .code64 generates the basic opcode (0f..)
  => in Eoan all three .code segments fail

Therefore it seems this part had major changes.
Not sure what to do, is this a bug in binutils that needs to be fixed?
Or was it a bug in IPXE that now is exposed?

I'd appreciate help by binutils-people.
@Doko when you read that you might ask some of your contacts maybe?

You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.

  FTBFS in Eoan - Error: operand type mismatch for `push' - gcc 9.2.1 /

Status in binutils package in Ubuntu:
Status in ipxe package in Ubuntu:

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:

  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 

  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:

Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to