On Wed, Apr 24, 2024 at 7:16 AM Florian Weimer <fweimer(a)redhat.com> wrote:
* Andrea Bolognani:
> Wouldn't changing -mabi effectively make the result a new Fedora
> architecture? IIUC, binaries built with -mabi=lp64d wouldn't be able
> to load libraries built with -mabi=lp64dv and vice versa.
>
> If that's correct, then we can't simply have a single "riscv64"
> architecture: instead, we need to call what we have today
> riscv64_lp64d, and be ready for riscv64_lp64dv as well as whatever
> comes next.
Right.
> It would be somewhat similar to existing architectures that can be
> used in both Little-Endian (ppc64le) and Big-Endian (ppc64) modes.
With different paths, it would be more like i686 and x86_64. That is,
you can build and run software for both variants from the same operating
system image. That's not the case for ppc64 and ppc64le.
As I recall, outside of the x86 family and s390x, all CPU platforms we
support are actually bi-endian and can have applications operate in
either mode. So I'm not sure that's a good example other than nobody
cared to specify parallel install paths for that.
> This is quite different from just bumping the ISA baseline,
where
> existing binaries and libraries are still usable in the new
> environment.
Right, changing the vector calling convention may change the size of
jmp_buf, and then you have a new ABI even if use of the vector features
is optional.
Arguably bumping the baseline should *also* be a new architecture
because it's a total compatibility break.
--
真実はいつも一つ!/ Always, there's only one truth!