Created attachment 15346 [details] entry32-16-debug.s Initially observed the failure on kexec-tools-2.0.27 package at https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/purgatory/arch/i386/entry32-16-debug.S#n28 Attached self-contained `entry32-16-debug.s` file. binutils-2.40 and 2.41 worked: $ as-2.40 --64 -o entry32-16-debug.o entry32-16-debug.s # ok binutils-2.42 fails as: $ as-2.42 --64 -o entry32-16-debug.o entry32-16-debug.s purgatory/arch/i386/entry32-16-debug.S: Assembler messages: purgatory/arch/i386/entry32-16-debug.S:28: Error: 64bit mode not supported on `i386'. $ as --version GNU assembler (GNU Binutils) 2.42 Copyright (C) 2024 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-unknown-linux-gnu'. Configured as: --prefix=/<<NIX>>/binutils-2.42 --bindir=/<<NIX>>/binutils-2.42/bin --sbindir=/<<NIX>>/binutils-2.42/sbin --includedir=/<<NIX>>/binutils-2.42-dev/include --oldincludedir=/<<NIX>>/binutils-2.42-dev/include --mandir=/<<NIX>>/binutils-2.42-man/share/man --infodir=/<<NIX>>/binutils-2.42-info/share/info --docdir=/<<NIX>>/binutils-2.42/share/doc/binutils --libdir=/<<NIX>>/binutils-2.42-lib/lib --libexecdir=/<<NIX>>/binutils-2.42-lib/libexec --localedir=/<<NIX>>/binutils-2.42-lib/share/locale --enable-64-bit-bfd --with-system-zlib --enable-deterministic-archives --disable-werror --enable-fix-loongson2f-nop --enable-new-dtags --program-prefix= --disable-gprofng --with-lib-path=: --enable-gold --enable-plugins --enable-shared --disable-static --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu
Might be related to https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=1d07cfb4406ee1dd336dd63cd5af7e8534892be7 ?
So this is precisely the case that the new behavior is intended to catch: It is meaningless to restrict ISA to i386 when trying to build 64-bit code. In the kexec example, the .code32 comes too late anyway (would have wanted to be at least before the label already before); wants moving ahead of the .arch. IOW for now I view this as neither a bug nor a regression; earlier gas simply was to lax. I'm open to be convinced otherwise ...
Aha, adapting kexec-tools sounds fine as well. Does the `.code16` use look fine in the rest of the file? SO far I made it build as: --- a/entry32-16-debug.s +++ b/entry32-16-debug.s @@ -18,10 +18,10 @@ .globl entry16_debug_pre32 .globl entry16_debug_first32 .globl entry16_debug_old_first32 + .code32 .arch i386 .balign 16 entry16_debug: - .code32 call 1f 1: popl %ebx Does it look about right?
(In reply to Sergei Trofimovich from comment #3) > Aha, adapting kexec-tools sounds fine as well. > > Does the `.code16` use look fine in the rest of the file? They're all okay, as there's no other .arch directive. Ordering there would be a problem only if you had e.g. ".arch i286" ahead of ".code16". > SO far I made it build as: >[...] > Does it look about right? Yes.
Thank you! Proposed kexec-tools fix as http://lists.infradead.org/pipermail/kexec/2024-January/029349.html Let's close as NOTABUG.