[RISCV] Clang-16 regressing build of inline assembly with Unsupported relocation type

[kraj]

The example below has worked fine with Clang 15 and also with Clang 16 branch of a week ago.

#define XREF_NOTE                                                              \
        ""                                                                 "\n"\
        "       .type _frr_xref_note,@object"                              "\n"\
        "       .pushsection .note.FRR,\"a\",@note"                        "\n"\
        "       .p2align 2"                                                "\n"\
        "_frr_xref_note:"                                                  "\n"\
        "       .long   9"                                                 "\n"\
        "       .long   16"                                                "\n"\
        "       .ascii  \"XREF\""                                          "\n"\
        "       .ascii  \"FRRouting\\0\\0\\0\""                            "\n"\
        "       .quad   __start_xref_array-."                              "\n"\
        "       .quad   __stop_xref_array-."                               "\n"\
        "       .size _frr_xref_note, .-_frr_xref_note"                    "\n"\
        "       .popsection"                                               "\n"\
        ""                                                                 "\n"\

void foo(void) {
  asm(XREF_NOTE);
}

$ clang -target riscv64-yoe-linux -mlittle-endian b.c -c
b.c:18:7: error: Unsupported relocation type
  asm(XREF_NOTE);
      ^
b.c:11:3: note: expanded from macro 'XREF_NOTE'
        "       .quad   __start_xref_array-."                              "\n"\
         ^
<inline asm>:10:8: note: instantiated into assembly here
        .quad   __start_xref_array-.
                ^
b.c:18:7: error: Unsupported relocation type
  asm(XREF_NOTE);
      ^
b.c:12:3: note: expanded from macro 'XREF_NOTE'
        "       .quad   __stop_xref_array-."                               "\n"\
         ^
<inline asm>:11:8: note: instantiated into assembly here
        .quad   __stop_xref_array-.
                ^
2 errors generated.

[kraj]

clang -target riscv64-yoe-linux -mlittle-endian b.c -c -no-integrated-as works ok too so seems internal asm specific.

[llvmbot]

@llvm/issue-subscribers-backend-risc-v

[asb]

Reproduced on current HEAD. Here is the version of the posted test case in .s form, needing only llvm-mc to reproduce.

	.text
	.attribute	4, 16
	.attribute	5, "rv64i2p0_m2p0_a2p0_c2p0"
	.file	"t.c"
	.globl	foo
	.p2align	1
	.type	foo,@function
foo:
	addi	sp, sp, -16
	sd	ra, 8(sp)
	sd	s0, 0(sp)
	addi	s0, sp, 16
	#APP

	.type	_frr_xref_note,@object
	.section	.note.FRR,"a",@note
	.p2align	2, 0x0
_frr_xref_note:
	.word	9
	.word	16
	.ascii	"XREF"
	.asciz	"FRRouting\000\000"
.Ltmp0:
	.quad	__start_xref_array-.Ltmp0
.Ltmp1:
	.quad	__stop_xref_array-.Ltmp1
.Ltmp2:
	.size	_frr_xref_note, .Ltmp2-_frr_xref_note
	.text



	#NO_APP
	ld	ra, 8(sp)
	ld	s0, 0(sp)
	addi	sp, sp, 16
	ret
.Lfunc_end0:
	.size	foo, .Lfunc_end0-foo

	.ident	"clang version 17.0.0"
	.section	".note.GNU-stack","",@progbits
	.addrsig

$ llvm-mc -triple riscv64 -filetype obj tc.s
tc.s:24:8: error: unsupported relocation type
        .quad   __start_xref_array-.Ltmp0
                ^
tc.s:26:8: error: unsupported relocation type
        .quad   __stop_xref_array-.Ltmp1
                ^

[asb]

Are you sure this previously worked in the Clang 16 branch? git bisect is putting the blame on 519a731 by @compnerd (committed Sep 2022). CC @MaskRay as well who reviewed that patch.

[asb]

This is fixed by D145474 which landed last night as 2f5fe16.

@MaskRay should we propose this for backporting to 16.0.1?

[kraj]

Are you sure this previously worked in the Clang 16 branch? git bisect is putting the blame on 519a731 by @compnerd (committed Sep 2022). CC @MaskRay as well who reviewed that patch.

I might be mis remembering as well. I realized that frr package in yocto did not build for RISCV before this commit
https://git.openembedded.org/meta-openembedded/commit/?id=d7b8c3a9f7185ae36f96058b6c8239cbaa55fc8e
which was added on last week :) so the problem in clang was always there, it just showed up after we started building frr for rv64

[kraj]

This is fixed by D145474 which landed last night as 2f5fe16.

@MaskRay should we propose this for backporting to 16.0.1?

yes please.

[nikic]

/cherry-pick 2f5fe16