dgilmore changed the topic of #fedora-riscv to: Fedora on RISC-V https://fedoraproject.org/wiki/Architectures/RISC-V || Logs: https://libera.irclog.whitequark.org/fedora-riscv || Alt Arch discussions are welcome in #fedora-alt-arches
zsun has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
tg has quit [Quit: tg]
zsun has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
zsun has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
<thefossguy> I’m now wondering what’s glibc doing now
<thefossguy> * I’m now wondering what’s glibc doing
<davidlt[m]> Most work is HW feature detection, vectors, and in general optimized stuff.
<thefossguy> Well, its not like I cant see the src but the GCC sources scare me 😳
<thefossguy> davidlt[m]: Do you mean this is the case for GCC and therefore its faster?
<thefossguy> *^faster at memcpy
<davidlt[m]> Well the article states that LLVM glibc memcpy is slower even with these patches compared to glibc.
<thefossguy> That was my initial question. Why is it slower? 😅  
<davidlt[m]> And glibc and GCC are independent projects.
<davidlt[m]> Probably less interest?
<thefossguy> Ah, gotcha for both 
<davidlt[m]> I am not sure what would actually use it.
<thefossguy> I recall ldd-ing my Rust binary and seeing it depend on libgcc_s. Was amusing ;)      
<davidlt[m]> That's gcc runtime bits.
<thefossguy> Yeah
<thefossguy> Is it possible to see which extensions a binary was compiled for? I'm trying to compile without the c extension but I don't think that it is working.
<thefossguy> Using this gcc command: gcc src/main.c -o rv64g-c -march=rv64imafd
<davidlt[m]> there is a flag in ELF headers IIRC for C.
<davidlt[m]> e_flags, bit 0 is for RVC
<thefossguy> I see this at the bottom of `readelf -a <bin>`
<thefossguy> ```
<thefossguy> ```
<thefossguy> Tag_RISCV_arch: "rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0_zmmul1p0"
<davidlt[m]> Yeah
<davidlt[m]> That's
<davidlt[m]> ```
<davidlt[m]> Tag_RISCV_arch contains a string for the target architecture taken from the option -march. Different architectures will be integrated into a superset when object files are merged.
<davidlt[m]> ```
<davidlt[m]> I think there were some discussions about it recently
<davidlt[m]> That you cannot trust it or something like that.
<thefossguy> It also has c2p0, which I assume is for the c extension. But I specifically didn't specify it.
<thefossguy> davidlt[m]: cannot trust `-march=<isa-string>`?
<thefossguy> s/>`?/>` to not be overridden by `-march=native`?/
<davidlt[m]> > One random fact of note: binutils stopped ascribing any information to
<davidlt[m]> > the tag a few releases ago, we found a show-stopped bug days before
<davidlt[m]> > release related to one of the ISA string spec changes and determined it
<davidlt[m]> > wasn't worth bothering with them any more.
<davidlt[m]> I think it even got disabled on the kernel side recently.
<thefossguy> Well, that's helpful /s
<thefossguy> I just wanna make sure that gcc doesn't use the c extension. Any way to make sure of this?
<thefossguy> It's a simple hello world c program
<davidlt[m]> march should be enough for that, I think.
<davidlt[m]> There is not native support in GCC, but it did land in LLVM/Clang recently.
<davidlt[m]> There is no way to detect what is "native" these days.
<davidlt[m]> Probably once hwprobe lands and get exposed via glibc, or something.
<thefossguy> Capstone doesn't seem to disassemble the '.text' section if the binary was built with compressed instructions... I'll try building with clang
<davidlt[m]> Are you cooking a binary, or and object file?
<davidlt[m]> I assume GCC run-time bits, etc. are compiled with C enabled.
<thefossguy> I'm disassembling a riscv binary
<davidlt[m]> Those will be linked in into the final binary.
<davidlt[m]> And, I guess, your GCC is not compiled with multi-lib support.
<thefossguy> Probably...
<davidlt[m]> It incl. things like rv64imafd (i.e. no C).
<davidlt[m]> If you compile an object file march is probably enough.
<davidlt[m]> If you actually cook executable that will most likely pull some GCC run-time bits that are with C.
<davidlt[m]> Unless your GCC is configured with multilib.
<thefossguy> I'll see how to get gcc multilib
<thefossguy> Don't wanna compile gcc :(
<davidlt[m]> In Fedora we don't support multi-lib, basically just one (the main one).
<davidlt[m]> Don't know about other distributions and how they configure their multi-lib.
<palmer> davidlt[m]: davide IIUC that's just for the embedded tool chain
<davidlt[m]> Ah yes, just now noticed the file name.
<thefossguy> I'll just wait for upstream to resolve this... <insert this is fine gif>
<thefossguy> Well who knew you could just look at the documentation? 😆
<thefossguy> Binaries built with rv64gc ISA-string and lp64d ABI now work
<nirik> Huh, this is interesting (possibly already mentioned, I'm behind on reading backscroll :) https://forum.rvspace.org/t/unlocking-new-possibilities-starfive-visionfive-2-sbc-now-supports-tianocore-edk-ii-uefi/2779
<nirik> TLDR: edk2 uefi support for visionfive2
<davidlt[m]> Yeah, we are well aware about it.
<davidlt[m]> Note that this doesn't incl. ACPI. UEFI + DT.
<nirik> figured.
<nirik> ah well, progress tho
<davidlt[m]> It just now we have two UEFI capable firmware options :)
<davidlt[m]> nirik: you might have missed this too: https://www.crowdsupply.com/milkv/milk-v-pioneer
<davidlt[m]> Seems it finally approaching general release.
<davidlt[m]> There is also a server platform with 2S, 128 cores, but that's a different product.
<nirik> did miss that one, thanks. ;)