This code was hackishly added in 2019 (__FreeBSD_version 1300070) to provide the forward compatibility, allowing to somehow run newer rtld on old kernel.
Details
Details
- Reviewers
tpearson_raptorengineering.com brooks
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
Comment Actions
Looks good to me on a POWER9 Blackbird / powerpc64le.
Thanks for putting this together!
Comment Actions
On second read through, caught a couple of code issues that don't affect functionality. Once those are fixed this looks good.
| libexec/rtld-elf/powerpc/reloc.c | ||
|---|---|---|
| 848 ↗ | (On Diff #166727) | This variable seems to be dangling. Remove? |
| libexec/rtld-elf/powerpc64/reloc.c | ||
| 745 ↗ | (On Diff #166727) | This variable seems to be dangling. Remove? |
Comment Actions
After thinking about this code some more, I realized that it probably should be removed altogether. Basically, it is there to allow to run newer binaries (rtld/libsys) on older (pre-AT_ renumbering) kernels. This was done in ~2019, and arguably outlived even the limited usefulness it had at the time of the commit.
Comment Actions
I'm not sure this analysis is entirely correct. __elfN(powerpc_copyout_auxargs) will use the old numbering if the binary is old (but not so old it doesn't have an OSREL embedded). What I'm not sure about is if this will happen with a new rtld and old binary or just with an old static binary.
That being said I'd like both bits to go away if possible. @tpearson_raptorengineering.com how important to you think old binary support is to the powerpc64 community?
(For additional context, my big complaint about POWER support in FreeBSD is that it's got a number of odd edges that require thought when making changes that should be machine independent. This one is arguably my fault in that I pushed for the AT_* consolidation, but it's still context I have to page in when I encounter the infrastructure.)
Comment Actions
One note from a ports maintainer perspective: rust currently uses FreeBSD 11 syscalls. Although those are new binaries, they need COMPAT_FREEBSD11, even for powerpc64le (which was introduced in 13.0). There is long-going plan to bump that to 12, but even then we'll still need COMPAT_FREEBSD12.
Another thing: dropping support for running old binaries (as in compiled long ago) is not an issue for me (and probably most users), but then ELFv1 support should probably also be dropped. We switched to ELFv2 in 13.0.
Comment Actions
I think you are right there. But for me this is an argument to remove the kernel compat as well: ppc* is tier-2, where we do not provide the ABI guarantees.
In other words, if we all agree, I will remove kernel copyout code and probably AT_OLD constants as well.
If not, then I will revert to my previous patch which removes all #ifdef __powerpc__ in the rtld code by adding arch hook for auxv mangling.
That being said I'd like both bits to go away if possible. @tpearson_raptorengineering.com how important to you think old binary support is to the powerpc64 community?
(For additional context, my big complaint about POWER support in FreeBSD is that it's got a number of odd edges that require thought when making changes that should be machine independent. This one is arguably my fault in that I pushed for the AT_* consolidation, but it's still context I have to page in when I encounter the infrastructure.)
Comment Actions
In my view, it's not important at all *except* if we start breaking ABIv2 binaries. In this case, we're not doing that, so I don't see a problem.
For historical context, we didn't really have any binary or even ISA level cross-device standardization (yes, I'm handwaving here, but let's be honest and call a spade a spade) until powerpc64[le] / OpenPOWER and the ABIv2 calling interface. In particular ABIv2 now relies on specific registers that are architected in powerpc64[le]and guaranteed to exist on all OpenPOWER compatible systems, and that's where Raptor basically draws the line with compatibility.
Further, 32 bit support is completely non-standardized, and Raptor's position is that we only care about 64 bit support, which is architected and standardized in a way that allows both cross-device binary execution and (theoretically) should allow cross-kernel binary execution.
(For additional context, my big complaint about POWER support in FreeBSD is that it's got a number of odd edges that require thought when making changes that should be machine independent. This one is arguably my fault in that I pushed for the AT_* consolidation, but it's still context I have to page in when I encounter the infrastructure.)
Let's see what we can do to clean those up. OpenPOWER (powerpc64[le]) != powerpc32, and we really don't need to carry any of that baggage forward. It's not helping the current users of the powerpc64le platform to have the maintainers fighting old cruft that's only still present to support obsolete, non-standardized CPUs. While I may not personally like it, if that extends to powerpc64 being the only remaining big endian platform and that fact becomes a problem for retaining the architecture, I have no major issues dropping the BE support as long as we keep the LE support around.
Comment Actions
I'm fine with dropping ELFv1 as well.
If it helps the non-powerpc folks, think of this as arm vs. aarch64. We don't need to keep "arm" (i.e. old legacy versions of binaries, 32 bit stuff, etc.) around, it's a fragmented mess, but we absolutely need "aarch64" (i.e. OpenPOWER / powerpc64[le] / ABIv2) which is in use at datacenter scale right now with new compatible devices becoming available from IBM (and potentially other players) every few years.