On Wed, Apr 24, 2024 at 8:35 AM Andrea Bolognani <abologna@xxxxxxxxxx> wrote: > > On Wed, Apr 24, 2024 at 07:43:08AM -0400, Neal Gompa wrote: > > On Wed, Apr 24, 2024 at 7:16 AM Florian Weimer <fweimer@xxxxxxxxxx> wrote: > > > > 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. > > So would you be able to natively run ppc64 binaries under a ppc64le > kernel? I don't think that'd be possible, but I don't have conclusive > proof so I could be wrong. > > Similarly, would you be able to run riscv64_lp64dv binaries under a > riscv64_lp64d kernel? That doesn't sounds like it would work either. > > And even if it did, you would still be unable to mix and match > binaries and libraries built for the two ABIs, so that makes them > separate Fedora architectures. > That's only the case if we don't have binary loaders that can deal with it. Which admittedly nobody has done on Linux, but it's not unheard of to have mixed ABI loading. In particular the situation of running binaries of one ABI under the kernel of another is something that has been done before even on x86. x32-on-x64 as well as i686-on-x86_64 are both examples of this, as is arm7hl-on-aarch64. That *we* don't do it in Fedora doesn't mean it's not possible. > > > > 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. > > No, you're just cutting off support for hardware that doesn't satsify > the new baseline. Which is obviously not something that should be > done lightly, but at least compatibility with existing binaries is > retained. Changing the ABI means starting from scratch. > Changing the baseline doesn't necessarily imply the ABI doesn't change. The fact that it generally *doesn't* doesn't mean that it *won't*. This is up to the compiler toolchain to handle, and since that's an implementation specific detail, I generally would not make that assumption. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
