<aurel32>
for now it seems nothing is ready for this change
<davidlt[m]>
aurel32: to my understanding nothing here todo
<aurel32>
with that change, at least u-boot, opensbi, linux and probably glibc do not build anymore
<davidlt[m]>
but that's most likely a build scripts issues, the binaries wise there is not incompatibilities IIUC
<davidlt[m]>
I did some chatting with Kito a day or two ago
<davidlt[m]>
I know that Palmer knows about the kernel already
<aurel32>
binutils throw warnings a link time about ABI mismatch, but I agree the binaries are still working
<davidlt[m]>
could you share an example?
<davidlt[m]>
I would expect more troubles once psABI finally get ratified (under review now)
<aurel32>
i wonder if compiler should change the baseline ABI used by many distro from rv64gc to rc64gc_zicsr_zifencei, or if we should just pass the correct -march= each time those instructions are used
<davidlt[m]>
So that's already the case with the patch Kito sent
<aurel32>
the warnings are like: /usr/bin/ld: warning: /usr/lib/gcc/riscv64-linux-gnu/11/crtn.o: mis-matched ISA version 2.0 for 'd' extension, the output version is 2.2
<davidlt[m]>
The RV64G alias means different things depending on the standard version
<aurel32>
i guess it's fixable by rebuilding everything
<davidlt[m]>
Ah, I don't recall the detail but the version is stored in the elf header somewhere
<aurel32>
note that's only with binutils from the 2.38 branch, still using gcc 11
zsun has joined #fedora-riscv
<aurel32>
maybe using gcc 12 helps there
<davidlt[m]>
There is a patch posted on Dec 30 for binutils:
<davidlt[m]>
[PATCH 1/2] RISC-V: Don't report mismatch warnings when versions are larger than 1.0.
<aurel32>
it doesn't seem to have been applied yet
<aurel32>
IMHO the warning are not the most problematic at this stage
<davidlt[m]>
I pinged Kito with your concerns, but he is offline right now
<aurel32>
ok, thanks
<davidlt[m]>
I am not so worried about: Error: unrecognized opcode `fence.i'
<aurel32>
why?
<davidlt[m]>
because that's build script change, which is relatively easy
<davidlt[m]>
and I don't expect a lot of packages to fail because of zifencei
<aurel32>
well it means changing many packages
<aurel32>
what about zicsr?
<davidlt[m]>
most packages shouldn't even directly call it IIRC
<aurel32>
it's used in glibc for instance
<davidlt[m]>
I would expect similar, but I don't have numbers
<davidlt[m]>
For the distro it might be beneficial to compile GCC 12 with old standard as default until the cleanups are done
<aurel32>
so you think zicsr and zifencei should not be made available by default on a generic distro?
<davidlt[m]>
That would remove at least immediate headache
<davidlt[m]>
They are, it's part of RV64GC
<aurel32>
yes that's my plan for binutils, i haven't look at binutils
<aurel32>
at least they are not available by default on the binutils side
<davidlt[m]>
RV64 is rv64imac in 2.2 spec, but it's rv64imac_zicsr_zifencei in all newer ones
<aurel32>
fix: yes that's my plan for binutils, i haven't look at gcc yet
<davidlt[m]>
new binutils isn't released yet :)
<davidlt[m]>
I think it was just branched several days ago, I wonder if this change depends on using binutils 2.38 (which sadly isn't part of Fedora 36)
<davidlt[m]>
Kito replied, that patch was forgotten (the binutils one)
<aurel32>
yes, IIRC it should be released in 2 weeks
<aurel32>
so it's the right moment to fix things
<aurel32>
we are using binutils from the 2.38 branch
<davidlt[m]>
Yeah, but sadly that's missed Fedora mass rebuild window :(
<aurel32>
and I just discovered all the mess
<aurel32>
well that is only the risc-v part, there was even more annoying bug affecting all architectures that just stop generating RELRO binaries in some cases
<aurel32>
so it's probably not that bad the rebuild window was missed ;)
<davidlt[m]>
There are so many issues being reported by GCC 12 mass rebuild that I am not starting Fedora/RISCV mass-rebuild for now.
<davidlt[m]>
the default would be (if no -march is passed): -march=rv64imac_zicsr_zifencei
<davidlt[m]>
it should be only an issue if defaults are changed (like -march)
<davidlt[m]>
otherwise nothing release changes
<davidlt[m]>
so opensbi, kernel, u-boot, grub and similar things most likely will have an issue
<aurel32>
yeah it happens that linux also sets also set -march
<davidlt[m]>
well, not sure about grub, but it does set -march IIRC
<davidlt[m]>
most (if not all) should be relatively easy fixes
<davidlt[m]>
but doing native builds and catching all the broken packages would take days in a proper distro
<davidlt[m]>
a bit annoying :)
zsun has quit [Quit: Leaving.]
<iooi>
davidlt[m]: I tried your stuff but it didn’t work: qemu-system-riscv64: --video: invalid option, qemu-system-riscv64: -video: invalid option, qemu-system-riscv64: --graphics: invalid option and qemu-system-riscv64: -graphics: invalid option but at least it was a helpful pointer to find this: https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/
<iooi>
Now I did the following: $ qemu-system-riscv64 \
<davidlt[m]>
Please, use pastebin services for any large output
<davidlt[m]>
Ah this is also the developer disk image which doesn't boot with UI by default
<davidlt[m]>
IIRC it includes X11 stuff, try : startx
<iooi>
I already tried startx, but from serial0 (since I could not log in on virtio-gpu-pci), it lost the connection: Failed to connect to bus: No such file or directory
<iooi>
xinit: connection to X server lost
* iooi
is afk
Jefro has joined #fedora-riscv
bkircher has joined #fedora-riscv
Jefro has quit [Quit: Client closed]
bkircher has quit [Ping timeout: 250 seconds]
<aurel32>
davidlt[m]: my new findings: from the binutils (as) point of view the g in rv64gc implies zicsr+zifencei
<aurel32>
so that's all good
<aurel32>
however from the gcc point of view, "-march=rv64gc" is translated into "-march=rv64gc -march=rv64imafdc" when passed to as
<aurel32>
so that doesn't work
<aurel32>
that's probably to support multilib
<aurel32>
so changing the canonicalization of g into imafd+zicsr+zifencei means changing the multilib dirs