On Wed, Apr 24, 2024 at 09:01:51AM -0400, Neal Gompa wrote: > 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. > > 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. Fair enough, but that's not the important point, this one is: > > 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. Even if you can figure out a way to run binaries targeting a ABI-A under a kernel targeting ABI-B, you still can't use the symbols coming from a library targeting ABI-A from a binary targeting ABI-B. And *that* is what makes them separate Fedora architectures. > > > > > 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. If changing the baseline results in a different ABI, then sure, that'd be a different Fedora architecture. But that's a much narrower criteria than "bumping the baseline should also be a new architecture". -- Andrea Bolognani / Red Hat / Virtualization -- _______________________________________________ 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
