Bug 29940 - fails to correctly assemble the JAL instruction on riscv64
Summary: fails to correctly assemble the JAL instruction on riscv64
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: gas (show other bugs)
Version: 2.40
: P2 critical
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL: https://bugs.debian.org/cgi-bin/bugre...
Keywords:
Depends on:
Blocks:
 
Reported: 2022-12-25 14:57 UTC by Aurelien Jarno
Modified: 2023-01-11 09:38 UTC (History)
2 users (show)

See Also:
Host: riscv64-unknown-linux-gnu
Target: riscv64-unknown-linux-gnu
Build: riscv64-unknown-linux-gnu
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aurelien Jarno 2022-12-25 14:57:52 UTC
inutils on riscv64 fails to correctly assemble the JAL instruction when
used without implicit register, that is in the format JAL reg, imm.
This can be reproduced with this simple test program:

.text
1:
    jal zero, 1b

With recent binutils versions, "zero" is not interpreted as a register,
but instead as the immediate value, and therefore a relocation is
emitted. This happens also when using other register names such as "a1"
or "x0". This causes the linux packages to fails to build due to
unresolved symbols in kernel modules:

ERROR: modpost: "zero" [arch/riscv/kvm/kvm.ko] undefined!
ERROR: modpost: "zero" [mm/z3fold.ko] undefined!
ERROR: modpost: "zero" [fs/mbcache.ko] undefined!
ERROR: modpost: "zero" [fs/fscache/fscache.ko] undefined!
ERROR: modpost: "zero" [fs/jbd2/jbd2.ko] undefined!
ERROR: modpost: "zero" [fs/nfs/nfs.ko] undefined!
ERROR: modpost: "zero" [fs/nfs/nfsv4.ko] undefined!
ERROR: modpost: "zero" [fs/nfsd/nfsd.ko] undefined!
ERROR: modpost: "zero" [fs/ufs/ufs.ko] undefined!
ERROR: modpost: "zero" [fs/xfs/xfs.ko] undefined!

The issue has been introduced by this commit:

commit 839189bc932ea02c9647a3ad829dda72f8a9562c
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Sep 30 10:19:00 2022 +0200

    RISC-V: re-arrange opcode table for consistent alias handling
    
    For disassembly to pick up aliases in favor of underlying insns (helping
    readability in the common case), the aliases need to come ahead of the
    "base" insns. Slightly more code movement is needed because of insns
    with the same name needing to stay next to each other.
    
    Note that the "rorw" alias entry also has the missing INSN_ALIAS added
    here.
    
    Clone a few testcases to exercise -Mno-aliases some more, better
    covering the differences between the default and that disassembly mode.

Reverting the first hunk of the opcodes/riscv-opc.c patch fixes the issue.
Comment 1 Andreas Schwab 2022-12-25 15:32:38 UTC
I cannot reproduce that.

$ echo '1:jal zero,1b' | gas/as-new && binutils/objdump -dr

a.out:     file format elf64-littleriscv


Disassembly of section .text:

0000000000000000 <.L1^B1>:
   0:   0000006f                j       0 <.L1^B1>
                        0: R_RISCV_JAL  .L1^B1
Comment 2 Aurelien Jarno 2022-12-25 16:12:55 UTC
Try with:

$ readelf -s a.out | grep GLOBAL
     7: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND zero
Comment 3 Andreas Schwab 2022-12-25 16:18:34 UTC
Nope.

$ binutils/objdump -t

a.out:     file format elf64-littleriscv

SYMBOL TABLE:
0000000000000000 l    d  .text  0000000000000000 .text
0000000000000000 l    d  .data  0000000000000000 .data
0000000000000000 l    d  .bss   0000000000000000 .bss
Comment 4 Andreas Schwab 2022-12-25 16:26:23 UTC
Used the wrong a.out.

$ binutils/objdump -t
a.out:     file format elf64-littleriscv

SYMBOL TABLE:
0000000000000000 l    d  .text  0000000000000000 .text
0000000000000000 l    d  .data  0000000000000000 .data
0000000000000000 l    d  .bss   0000000000000000 .bss
0000000000000000 l    d  .riscv.attributes      0000000000000000 .riscv.attributes
0000000000000000         *UND*  0000000000000000 zero
Comment 5 Jan Beulich 2023-01-04 07:42:28 UTC
IOW it's not a relocation which is being emitted, but there are stray (and unused) symbol table entries now (referencing register names).
Comment 6 Sourceware Commits 2023-01-11 09:31:57 UTC
The master branch has been updated by Jan Beulich <jbeulich@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f56532cc17868e2c7e765bfd78322157048ff6ec

commit f56532cc17868e2c7e765bfd78322157048ff6ec
Author: Jan Beulich <jbeulich@suse.com>
Date:   Wed Jan 11 10:31:43 2023 +0100

    gas/RISC-V: adjust assembler for opcode table re-ordering
    
    PR gas/29940
    
    With the single-operand JAL entry now sitting ahead of the two-operand
    one, the parsing of a two-operand insn would first try to parse an 'a'-
    style operand, resulting in the insertion of bogus (and otherwise
    unused) undefined symbols in the symbol table, having register names.
    Since 'a' is used as 1st operand only with J and JAL, and since JAL is
    the only insn _also_ allowing for a register as 1st operand (and then
    there being a 2nd one), special case this parsing aspect right there.
    
    Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
Comment 7 Sourceware Commits 2023-01-11 09:36:12 UTC
The binutils-2_40-branch branch has been updated by Jan Beulich <jbeulich@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ad2021a0f761e23576820aca50a7ac10d7f40bed

commit ad2021a0f761e23576820aca50a7ac10d7f40bed
Author: Jan Beulich <jbeulich@suse.com>
Date:   Wed Jan 11 10:31:43 2023 +0100

    gas/RISC-V: adjust assembler for opcode table re-ordering
    
    PR gas/29940
    
    With the single-operand JAL entry now sitting ahead of the two-operand
    one, the parsing of a two-operand insn would first try to parse an 'a'-
    style operand, resulting in the insertion of bogus (and otherwise
    unused) undefined symbols in the symbol table, having register names.
    Since 'a' is used as 1st operand only with J and JAL, and since JAL is
    the only insn _also_ allowing for a register as 1st operand (and then
    there being a 2nd one), special case this parsing aspect right there.
    
    Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
Comment 8 Jan Beulich 2023-01-11 09:38:24 UTC
Fixed on master as well as the branch.