Launchpad has imported 1 comments from the remote bug at https://sourceware.org/bugzilla/show_bug.cgi?id=25012.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2019-09-18T15:30:24+00:00 Christian Ehrhardt wrote: Hi, I have found that with recent binutils ipxe was no more compiling. It broke on a section doing essentially (simplified) doing: .code64 pushq %gs pushq %fs popq %gs popq %fs The fail I got was like: push.S:2: Error: unsupported instruction `push' push.S:3: Error: unsupported instruction `push' push.S:4: Error: unsupported instruction `pop' push.S:5: Error: unsupported instruction `pop' There is more about that in Ubuntu bug https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1843394 But I'm reaching out to you here as I was wondering if it is a bug in gas (unlikely, but it is a change in behavior for sure). I found that even older 2.32 are ok. 2.32-7ubuntu4 - ok 2.32.51.20190905-0ubuntu1 - fails. I was wondering and hoping you could help me on three things: 1. was the change to no more build that assembly intentional and could one maybe link to a commit for that? 2. if the change was intentional is there a best practice how the code should be modified to work again? 3. I was checking the behavior on push/pop %fs/gs and it confused me so I wonder if the current state is correct (see attachment and below). For #3 some details: 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 I wonder if all of that is correct? P.S. I can break this up into multiple bugs if you tell me which section you want to discuss separately. P.P.S. I have asked upstream IPXE for feedback for (a pure gut feeling) change, but there was no response yet (http://lists.ipxe.org/pipermail/ipxe-devel/2019-September/006763.html) Reply at: https://bugs.launchpad.net/ubuntu/+source/ipxe/+bug/1843394/comments/12 ** Changed in: binutils Status: Unknown => New ** Changed in: binutils Importance: Unknown => Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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: New 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
