| Issue |
123077
|
| Summary |
llvm-mc uses wrong ABI for RISC-V platform on Linux by default
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
directhex
|
This is a related issue to https://github.com/llvm/llvm-project/issues/115679 and possibly https://github.com/llvm/llvm-project/issues/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.
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
