Created attachment 7799 [details] /proc/cpuinfo Recently attempted a Linux kernel build, and several files fail to assemble using GNU as 2.24 on one of my machines, throwing an internal error in the x86 output_insn function. Note that this error only occurs on one of my three machines (Haswell CPU), the other two (Phenom II and Sandy Bridge CPUs) are unaffected despite using the same package versions and kernel build configuration. /proc/cpuinfo attached. Using Arch Linux binutils 2.24-7 package, and building the current snapshot of Linus' tree (3c2ea7024) with a silentoldconfig configuration. > export KCFLAGS="-march=native -O2 -pipe" > export KCPPFLAGS="-march=native -O2 -pipe" > make -j4 CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CALL scripts/checksyscalls.sh CHK include/generated/compile.h CHK kernel/config_data.h CC arch/x86/boot/cpucheck.o VOFFSET arch/x86/boot/voffset.h {standard input}: Assembler messages: {standard input}:32: Internal error, aborting at /build/binutils/src/binutils-2.24/gas/config/tc-i386.c line 6969 in output_insn Please report this bug. scripts/Makefile.build:257: recipe for target 'arch/x86/boot/cpucheck.o' failed make[1]: *** [arch/x86/boot/cpucheck.o] Error 1 make[1]: *** Waiting for unfinished jobs.... Will try to generate a more minimal repro than a kernel build though.
Since you use -march=native it's not surprising to see different results on different machines. Please repeat the kernel build on the failing machine with "make V=1 -j1" and capture the full gcc invocation for the file that crashed gas (cpucheck.c). Then repeat that gcc invocation with "-S" appended to the options. That should leave a cpucheck.s that crashes gas. Attach that file here.
Created attachment 7800 [details] Input that fails to assemble
Looking at the V=1 output, the Makefile never calls gas directly but relies on the gcc command. > gcc -Wp,-MD,arch/x86/boot/.cpucheck.o.d -D__KERNEL__ -march=native ... -c -o arch/x86/boot/.tmp_cpucheck.o arch/x86/boot/cpucheck.c Changing the "-c" to a "-S" gives me the attached file. It fails to compile on my system, even *without* passing any of these arguments to gas (env is clean too). > # as cpucheck.S -c -o .tmp.o > cpucheck.S: Assembler messages: > cpucheck.S:32: Internal error, aborting at /build/binutils/src/binutils-2.24/gas/config/tc-i386.c line 6969 in output_insn Please report this bug.
Created attachment 7801 [details] reduced test case Seems like .code16gcc and the "andn" instruction don't work together. > cat bz17421.s .code16gcc .text andn req_flags(,%edx,4), %ecx, %ecx > as bz17421.s bz17421.s: Assembler messages: bz17421.s:3: Internal error, aborting at config/tc-i386.c line 6340 in output_insn Please report this bug. > as --version GNU assembler version 2.23.52.0.1-9.fc19 20130226 Copyright 2013 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-redhat-linux'.
(In reply to Mikael Pettersson from comment #4) > Created attachment 7801 [details] > reduced test case > > Seems like .code16gcc and the "andn" instruction don't work together. > > > cat bz17421.s > .code16gcc > .text > andn req_flags(,%edx,4), %ecx, %ecx According to Intel SDM, andn isn't supported in 16-bit mode. "gcc -m16" should turn off MMX, SSE, AVX as well as VEX-encoded scalar instructions.
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "gdb and binutils". The branch, master has been updated via 9e5e52835bb205850fb0fa6f0393ecd64b02b22f (commit) from c4d9ceb6473237e614c66be97351109b9f260505 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9e5e52835bb205850fb0fa6f0393ecd64b02b22f commit 9e5e52835bb205850fb0fa6f0393ecd64b02b22f Author: H.J. Lu <hjl.tools@gmail.com> Date: Tue Sep 23 11:12:23 2014 -0700 Disallow VEX/EVEX encoded instructions in 16-bit mode gas/ PR gas/17421 * config/tc-i386.c (md_assemble): Disallow VEX/EVEX encoded instructions in 16-bit mode. gas/testsuite/ PR gas/17421 * gas/i386/i386.exp: Run inval-16. * gas/i386/inval-16.l: New file. * gas/i386/inval-16.s: Likewise. ----------------------------------------------------------------------- Summary of changes: gas/ChangeLog | 6 ++++++ gas/config/tc-i386.c | 17 +++++++++++++---- gas/testsuite/ChangeLog | 8 ++++++++ gas/testsuite/gas/i386/i386.exp | 1 + gas/testsuite/gas/i386/inval-16.l | 20 ++++++++++++++++++++ gas/testsuite/gas/i386/inval-16.s | 9 +++++++++ 6 files changed, 57 insertions(+), 4 deletions(-) create mode 100644 gas/testsuite/gas/i386/inval-16.l create mode 100644 gas/testsuite/gas/i386/inval-16.s
Fixed.
As was pointed out in email (https://sourceware.org/ml/binutils/2014-09/msg00204.html), the fix is wrong and should be reverted/adjusted: VEX-encoded instructions are, according to current documentation at least, only unsupported in Real and VM86 modes; 16-bit protected mode is not being listed in section "Exception Conditions for VEX-Encoded GPR Instructions" (and similarly for any of the SIMD ones).