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 Bugs, which is subscribed to 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 To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/1843394/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
