jjido has quit [Quit: My laptop has gone to sleep. ZZZzzz…]
jjido has joined #riscv
jjido has quit [Quit: My laptop has gone to sleep. ZZZzzz…]
guerby_ has joined #riscv
guerby has quit [Ping timeout: 244 seconds]
guerby_ has quit [Ping timeout: 244 seconds]
guerby has joined #riscv
cronos has quit [Server closed connection]
cronos has joined #riscv
Kyuvi has joined #riscv
rattlesnake has quit [Read error: Connection reset by peer]
rattlesnake has joined #riscv
jjido has joined #riscv
___nick___ has quit [Ping timeout: 256 seconds]
<drewfustini>
palmer: or others, I'm trying to find where it is documented what registers can be clobbered across a syscall. The psABI says look at execution environment and SBI spec says: "All registers except a0 & a1 must be preserved across an SBI call by the callee."
<drewfustini>
I've been looking through the arch/riscv code but am I missing something explicit? It seems like only the vector registers are mentioned in Documentation.
<drewfustini>
Though I guess U to S is not an SBI call, so I'm not sure what spec covers it
<khem>
drewfustini:do you mean SBI calls or syscalls
<khem>
IIRC from userspace side Syscall argument/return convention a7 = number, a0–a5 = args, a0 = result/-errno
fgarcia has quit [Quit: Remote host closed the connection]
fgarcia has joined #riscv
dramforever[m]1 has joined #riscv
<dramforever[m]1>
khem: the problem is what *other* registers should do in this case
<dramforever[m]1>
i don't think this was ever defined on account of possibly it not being the business of riscv to define what an os does
jjido has quit [Quit: My laptop has gone to sleep. ZZZzzz…]
<dramforever[m]1>
i think the glibc inline asm is just wrong
<dramforever[m]1>
it probably happens to work by virtue of being inside some wrapper that doesn't care about vector regs
<dramforever[m]1>
maybe we should just move that to a separate `.S` and enjoy the function call abi while waiting for rust's clobber_abi("C") to show up in gcc and clang...
<dramforever[m]1>
(yes i recognize that this also requires knowing what the actual abi is which was the original question)
<jrtc27>
musl doesn't think syscalls clobber any registers other than a0
jjido has joined #riscv
ruidx has quit [Quit: WeeChat 3.8]
<jrtc27>
on FreeBSD our ABI (as far as I know) clobbers a0, a1 and t0
<jrtc27>
but we also don't provide the whole syscall macro thing
ruidx has joined #riscv
<jrtc27>
our syscall(2), along with other syscalls that don't have custom C wrapper bits, is a function in its own .S file and follows the normal calling convention
<Tenkawa>
jrtc27: at least on risc-v is there any dependency on the soc having the vector extension? This has been a very touchy subject in the hardware area so far in risc-v development...
<jrtc27>
for what?
<Tenkawa>
This bug..
<jrtc27>
I don't understand what you're asking
<jrtc27>
this is about glibc defining its inline asm correctly when being compiled with V enabled
<Tenkawa>
Yes... on certain risc-v hardware "V" is "non-existent"
<dramforever[m]1>
this has nothing to do with hardware development
<dramforever[m]1>
this is whether you have -march=+v while compiling glibc
<jrtc27>
if you want a more applicable awkward question: doing this with function multi-versioning won't go well
<Tenkawa>
dramforever[m]1: Its been a "constant" discussion point so far so I'm not sure i would agree with that generalization
<jrtc27>
given this is a single preprocessor check in a header, not based on __attribute__((__target__)) for the function (or __target_clones__)
jmcgnh has joined #riscv
<jrtc27>
Tenkawa: which profiles require V and which OSes require those profiles can be a contentious topic
<jrtc27>
this is not about that at all
<dramforever[m]1>
Tenkawa: i still don't get what the point even is
<jrtc27>
this is about saying *if* you have asked glibc for V, for whatever reason that may be, does it function correctly?
<jrtc27>
so unless your view is "V should not exist as an extension", that is something that glibc should support
<Tenkawa>
Ok.. It won't matter... good enough.
<jrtc27>
really don't understand why that isn't more than good enough, but whatever
Tenkawa has quit [Quit: Was I really ever here?]
Kyuvi has quit [Ping timeout: 250 seconds]
vagrantc has quit [Quit: leaving]
jjido has quit [Quit: My laptop has gone to sleep. ZZZzzz…]