https://sourceware.org/bugzilla/show_bug.cgi?id=29004
remuladgryta <foss at remuladgryta dot se> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |foss at remuladgryta dot se
--- Comment #3 from remuladgryta <foss at remuladgryta dot se> ---
(In reply to Nelson Chu from comment #2)
>
> Not sure what's . fails mean. I can get the same symbol value 8 for
> _thread, when using . and 9f:
>
> % cat tmp.s
> .macro _header_ name, cfa
> .section .data # assemble into head space
> .quad _thread
> .set _thread, .
> 8: # address to link next word header against
> .string "\name"
> .set lex, 0
> .quad \cfa # point header at new words cfa
> .previous # assemble into list space
> .endm
>
> _header_ A, B
> % riscv64-unknown-elf-as -mno-arch-attr tmp.s -o tmp.o
> % riscv64-unknown-elf-readelf -Ws tmp.o
>
> Symbol table '.symtab' contains 7 entries:
> Num: Value Size Type Bind Vis Ndx Name
> 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
> 1: 0000000000000000 0 SECTION LOCAL DEFAULT 1 .text
> 2: 0000000000000000 0 SECTION LOCAL DEFAULT 2 .data
> 3: 0000000000000000 0 SECTION LOCAL DEFAULT 4 .bss
> 4: 0000000000000008 0 NOTYPE LOCAL DEFAULT 2 _thread
> 5: 0000000000000000 0 NOTYPE LOCAL DEFAULT ABS lex
> 6: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND B
>
I recently ran into this issue while porting a FORTH implementation to RISC-V
(it looks like OP was doing the same, cfa is a FORTH acronym for code field
address).
The first invocation of the macro is fine, but it blows up on subsequent
invocations:
% cat tmp.s
# In FORTH, functions (words) are stored in a linked-list dictionary.
# A dictionary entry is typically a header followed by the function body.
# The FORTH VM keeps track of the most recently defined word so that words
# can be looked up by name at runtime by walking the dictionary.
.set link, 0
.macro HEADER name, code
_header_\name:
.int link # the header has a pointer to the preceding entry
.set link, _header_\name
.ascii "\name" # and the name of the word
.int \code # and a pointer to its function body
.endm
HEADER FOO, code_FOO
code_FOO:
nop # code body of the word FOO
HEADER BAR, code_BAR
code_BAR:
nop # code body of the word BAR
# some words are aliases or have other special semantics,
# so machine code doesn't always follow the header
HEADER BAZ, code_BAR
% riscv64-unknown-elf-as tmp.s -o tmp.o
tmp.s: Assembler messages:
tmp.s:19: Error: redefined symbol cannot be used on reloc
tmp.s:25: Error: redefined symbol cannot be used on reloc
The same file does assemble using, say, x86_64-linux-gnu-as:
% x86_64-linux-gnu-readelf -Ws tmp.o
Symbol table '.symtab' contains 8 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 SECTION LOCAL DEFAULT 1 .text
2: 0000000000000018 0 NOTYPE LOCAL DEFAULT 1 link
3: 0000000000000000 0 NOTYPE LOCAL DEFAULT 1 _header_FOO
4: 000000000000000b 0 NOTYPE LOCAL DEFAULT 1 code_FOO
5: 000000000000000c 0 NOTYPE LOCAL DEFAULT 1 _header_BAR
6: 0000000000000017 0 NOTYPE LOCAL DEFAULT 1 code_BAR
7: 0000000000000018 0 NOTYPE LOCAL DEFAULT 1 _header_BAZ
A workaround is possible, but cumbersome and error prone:
% cat workaround.s
# In FORTH, functions (words) are stored in a linked-list dictionary.
# A dictionary entry is typically a header followed by the function body.
# The FORTH VM keeps track of the most recently defined word so that words
# can be looked up by name at runtime by walking the dictionary.
.macro HEADER name, code, backlink
_header_\name:
.int backlink # the header has a pointer to the preceding entry
.ascii "\name" # and the name of the word
.int \code # and a pointer to its function body
.endm
HEADER FOO, code_FOO
code_FOO:
nop # code body of the word FOO
HEADER BAR, code_BAR, name_FOO
code_BAR:
nop # code body of the word BAR
# some words are aliases or have other special semantics,
# so machine code doesn't always follow the header
HEADER BAZ, code_BAR, name_BAR
% riscv64-unknown-elf-as workaround.s -o workaround.o
% riscv64-unknown-elf-readelf -Ws workaround.o
Symbol table '.symtab' contains 17 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 SECTION LOCAL DEFAULT 1 .text
2: 0000000000000000 0 SECTION LOCAL DEFAULT 3 .data
3: 0000000000000000 0 SECTION LOCAL DEFAULT 4 .bss
4: 0000000000000000 0 NOTYPE LOCAL DEFAULT 1 _header_FOO
5: 0000000000000000 0 NOTYPE LOCAL DEFAULT 1 $d
6: 000000000000000b 0 NOTYPE LOCAL DEFAULT 1 code_FOO
7: 000000000000000b 0 NOTYPE LOCAL DEFAULT 1
$xrv64i2p1_m2p0_a2p1_f2p2_d2p2_zicsr2p0_zifencei2p0_zmmul1p0
8: 000000000000000f 0 NOTYPE LOCAL DEFAULT 1 _header_BAR
9: 000000000000000f 0 NOTYPE LOCAL DEFAULT 1 $d
10: 000000000000001a 0 NOTYPE LOCAL DEFAULT 1 code_BAR
11: 000000000000001a 0 NOTYPE LOCAL DEFAULT 1 $x
12: 000000000000001e 0 NOTYPE LOCAL DEFAULT 1 _header_BAZ
13: 000000000000001e 0 NOTYPE LOCAL DEFAULT 1 $d
14: 0000000000000029 0 NOTYPE LOCAL DEFAULT 1 $x
15: 0000000000000000 0 SECTION LOCAL DEFAULT 5 .riscv.attributes
16: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND backlink
--
You are receiving this mail because:
You are on the CC list for the bug.
