Open Quuxplusone opened 4 years ago
This looks like a general problem with LLVM's assembler support for LOCAL
in .altmacro
systems.
I can confirm this issue is target-independent. I wrote a small piece piece of
code to help myself understand the exact meaning of LOCAL. I'm putting it down
for future reference.
$ cat foo.s
.altmacro
.set x, 0
.macro write arg
.set x, \arg
mov x, %eax
.endm
.macro read
mov x, %ebx
.endm
write 16
read
$ as foo.s -o gas.o
$ objdump -d gas.o
gas.o: file format elf64-x86-64
Disassembly of section .text:
0000000000000000 <.text>:
0: 8b 04 25 10 00 00 00 mov 0x10,%eax
7: 8b 1c 25 10 00 00 00 mov 0x10,%ebx
Without LOCAL, the value of symbol "x" defined in the expansion of foo got read
in the macro expansion of bar. If I make "x" local in foo, then it's renamed
uniquely for each expansion of foo, and as a result bar would read its initial
value 0 instead.
$ cat foo.s
.altmacro
.set x, 0
.macro write arg
LOCAL x
.set x, \arg
mov x, %eax
.endm
.macro read
mov x, %ebx
.endm
write 16
read
$ as foo.s -o gas.o
$ objdump -d gas.o
gas.o: file format elf64-x86-64
Disassembly of section .text:
0000000000000000 <.text>:
0: 8b 04 25 10 00 00 00 mov 0x10,%eax
7: 8b 1c 25 00 00 00 00 mov 0x0,%ebx
Sent https://reviews.llvm.org/D105720 for review.
Buiding the RISC-V Linux kernel w/ Clang, we hit this error, ex: