llvm-mc uses wrong ABI for RISC-V platform on Linux by default

[directhex]

This is a related issue to #115679 and possibly #50591. Generally, the default ABI handling is done differently in every tool, where https://reviews.llvm.org/D69383 defined the current behaviour for clang.

Roughly speaking, it is reasonable for a user to expect these two compiler invocations to act in an equivalent way:

$ clang -o bottles.o bottles.c

$ clang -S -o bottles.S bottles.c
$ llvm-mc --filetype=obj -o bottles.o bottles.S

However, they don't. Without use of the (undocumented) -target-abi=lp64d flag, llvm-mc targets a different ABI and the resulting object files cannot be linked with objects produced by clang/clang++

Per the changes in D69383 to clang/lib/Driver/ToolChains/Arch/RISCV.cpp, the logic used by clang to this day is:

    if (Triple.getOS() == llvm::Triple::UnknownOS)
      return "lp64";
    else
      return "lp64d";

i.e. use lp64 unless a named OS is used, in which case use lp64d. Explicitly forcing an OS into the triple (i.e. passing -triple riscv64-unknown-linux-gnu to llvm-mc) does not result in the clang behaviour of defaulting to lp64d when calling llvm-mc.

As time allows, I intend to try and get a PR filed to unify llvm-mc's behaviour - I wanted to document the issue first.

[directhex]

so llvm/lib/MC/MCTargetOptionsCommandFlags.cpp's llvm::mc::RegisterMCTargetOptionsFlags::RegisterMCTargetOptionsFlags() is used by llvm-mc and loads the default via Options.ABIName = getABIName(). Getting a bit lost in what's being included from where, but I have a bad feeling about computeTargetABI in llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.cpp being the problem (specifically https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.cpp#L77-L81 sure feels like it's parsing feature bits but not considering target OS, which is the differentiator used between lp64/lp64d defaults in clang)

[topperc]

As far as I know, llvm-mc also doesn't default to having F and D extensions enabled. You need to add -mattr=+d. I think adding -mattr=+d will change the default ABI.

[directhex]

As far as I know, llvm-mc also doesn't default to having F and D extensions enabled. You need to add -mattr=+d. I think adding -mattr=+d will change the default ABI.

llvm-mc will throw a warning without -mattr=+d, but it does emit an object with the correct ELF tags in it at least:

$ llvm-mc -o bottles.o bottles.S --filetype=obj
$ file bottles.o 
bottles.o: ELF 64-bit LSB relocatable, UCB RISC-V, soft-float ABI, version 1 (SYSV), not stripped

$ llvm-mc -target-abi=lp64d -o bottles.o bottles.S --filetype=obj
Hard-float 'd' ABI can't be used for a target that doesn't support the D instruction set extension (ignoring target-abi)
$ file bottles.o 
bottles.o: ELF 64-bit LSB relocatable, UCB RISC-V, double-float ABI, version 1 (SYSV), not stripped

$ llvm-mc -mattr=+d -o bottles.o bottles.S --filetype=obj
$ file bottles.o
bottles.o: ELF 64-bit LSB relocatable, UCB RISC-V, double-float ABI, version 1 (SYSV), not stripped

I would need a more sophisticated test file than 99 bottles to see what the actual ABI looks like in the .o file, beyond the claims made in the ELF flag. And the point remains that the defaults don't match between tools.

[topperc]

And the point remains that the defaults don't match between tools.

I'm not sure llvm-mc should have OS triple dependent behavior. It's a low level tool.

CC @MaskRay

[arichardson]

And the point remains that the defaults don't match between tools.

I'm not sure llvm-mc should have OS triple dependent behavior. It's a low level tool.

CC @MaskRay

I agree with this and would not want any of that logic in these developer tools.

That said I know many years ago I initially got confused about llvm-mc and thought it could be used as a replacement for GNU as. Maybe the real solution here is to provide a hypothetical clang-as tool that defaults to processing assembly input (and maybe add support for some of the gnu as flags?).

[directhex]

That said I know many years ago I initially got confused about llvm-mc and thought it could be used as a replacement for GNU as. Maybe the real solution here is to provide a hypothetical clang-as tool that defaults to processing assembly input (and maybe add support for some of the gnu as flags?).

I assume some relevant code owner would need to sign off on that concept before I sit down & try to implement it