llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
27.17k stars 11.12k forks source link

Clang produces broken reproducers when invoked as assembler #77028

Open brooksdavis opened 6 months ago

brooksdavis commented 6 months ago

TL;DR: if clang crashes when invoked as an assembler on a .S file (assembly with CPP directives) it produces a reproducer that doesn't work due to a mismatch between the invocation of clang -cc1as and the partially preprocessed source file. It's unclear if the source should be more fully processed or the command in the .sh file should be different.

Due to a bug in assembly I hit an assert in the PowerPC backend.

Assertion failed: (MO.isImm() && "Relocation required in an instruction that we cannot encode!"), function getMachineOpValue, file /home/bed22/cheri/freebsd/contrib/llvm-project/llvm/lib/Target/PowerPC/MCTargetDesc/PPCMCCodeEmitter.cpp, line 406.
PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.      Program arguments: /home/bed22/tmp/obj/home/bed22/cheri/freebsd/powerpc.powerpc64/tmp/usr/bin/clang -cc1as -triple powerpc-unknown-freebsd15.0 -filetype obj -main-file-name symlink-7b6cec.S -target-cpu ppc -target-feature +secure-plt -fdebug-compilation-dir=/tmp -dwarf-debug-producer "FreeBSD clang version 17.0.6 (https://github.com/llvm/llvm-project.git llvmorg-17.0.6-0-g6009708b4367)" -debug-info-kind=constructor -dwarf-version=4 -mrelocation-model static -object-file-name=/dev/null -o /dev/null /tmp/symlink-7b6cec-448e06.s
#0 0x0000000003a27ca6 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/bed22/tmp/obj/home/bed22/cheri/freebsd/powerpc.powerpc64/tmp/usr/bin/clang+0x3a27ca6)
#1 0x0000000003a26175 llvm::sys::RunSignalHandlers() (/home/bed22/tmp/obj/home/bed22/cheri/freebsd/powerpc.powerpc64/tmp/usr/bin/clang+0x3a26175)
#2 0x0000000003a2823e SignalHandler(int) (/home/bed22/tmp/obj/home/bed22/cheri/freebsd/powerpc.powerpc64/tmp/usr/bin/clang+0x3a2823e)
#3 0x00000000049397df handle_signal (/home/bed22/tmp/obj/home/bed22/cheri/freebsd/powerpc.powerpc64/tmp/usr/bin/clang+0x49397df)
clang: error: unable to execute command: Abort trap (core dumped)
clang: error: clang integrated assembler command failed due to signal (use -v to see invocation)
FreeBSD clang version 17.0.6 (https://github.com/llvm/llvm-project.git llvmorg-17.0.6-0-g6009708b4367)
Target: powerpc-unknown-freebsd15.0
Thread model: posix
InstalledDir: /home/bed22/tmp/obj/home/bed22/cheri/freebsd/powerpc.powerpc64/tmp/usr/bin
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/symlink-7b6cec.S
clang: note: diagnostic msg: /tmp/symlink-7b6cec.sh
clang: note: diagnostic msg: 

********************

Clang dutifully produced the reproducers in https://gist.github.com/brooksdavis/4f2f973eb0c001603e79143233418450 which fail to reproduce the problem with many errors which look like it's trying to parse unexpanded macros as assembly.

/home/bed22/cheri/freebsd/lib/libsys/../libc/include/compat.h:42:22: error: expected ')'
__sym_compat(__semctl, freebsd7___semctl, FBSD_1.0);
                     ^
/home/bed22/cheri/freebsd/lib/libsys/../libc/include/compat.h:42:13: error: unknown operand
__sym_compat(__semctl, freebsd7___semctl, FBSD_1.0);
            ^
...

I believe the issue is that clang -cc1as expects a fully processed assembly file, not one where includes have been embedded. The file is a hacked up version of the reproducer script that invokes clang in a way that actually triggers the crash.

shafik commented 6 months ago

CC @AaronBallman @erichkeane

erichkeane commented 6 months ago

cc1as is the assembler, not the frontend, so has nothing to do with Aaron or myself. But changed to the llvm-as tool, which I hope is the right one.

brooksdavis commented 6 months ago

cc1as is the assembler, not the frontend, so has nothing to do with Aaron or myself. But changed to the llvm-as tool, which I hope is the right one.

It seems unlikely llvm-as is the right thing given that llvm-as compiles IR to bytecode... I think it's probably clang:driver.