Palmer Dabbelt palmer@dabbelt.com
Mon Aug 8 18:33:15 GMT 2022

On Mon, 08 Aug 2022 10:27:42 PDT (-0700), binutils@sourceware.org wrote:
> On 2022-08-08, Kito Cheng wrote:
>>Hi Andreas:
>>> FWIW, they are still generically handled by the .vtable_inherit and
>>> .vtable_entry pseudo-ops, but support for -fvtable-gc has been removed
>>> from gcc in 2003.  The RISC-V assembler never picked them up.
>>Thanks for the historical data! RISC-V GNU toolchain is upstreamed
>>after that time, so sounds like we could remove that safely for
> Second this.

Given the age I'm assuming LLVM never supported this on RISC-V either, 
so this seems reasonable to me.

IMO we can't re-use the relocation numbers, so maybe we should leave 
some sort of deprecated stub in there just in case?  Not sure that's 
even worth it in this case, though.

>>> $ riscv64-suse-linux-as vtable.s
>>> vtable.s: Assembler messages:
>>> vtable.s:1: Error: cannot represent BFD_RELOC_VTABLE_ENTRY relocation in object file
>>> vtable.s:2: Error: cannot represent BFD_RELOC_VTABLE_INHERIT relocation in object file
>>Maybe we can improve the error message into something like:
>>.vtable_inherit / .vtable_entry is unsupported for RISC-V.
> I think the diagnostic is from gas/config/tc-riscv.c:4135 .
> Since gcc -fvtable-gc was gone in 2003 and we essentially cannot find
> .vtable_entry uses, I think sticking with the existing generic diagnostic isn't bad.

More information about the Binutils mailing list