Simon McVittie dixit: >On Wed, 05 Jul 2023 at 17:22:14 +0100, Wookey wrote: […] >> i.e we could keep the existing i386 for the gamers and have i386t64 >> (or whatever we call it) for ongoing use of i386 as a real OS. > >On Fri, 09 Jun 2023 at 16:39:38 +0000, Thorsten Glaser wrote: >> Ideally we’d keep the old i386 around for legacy binary-only libraries >> and executables and add an i586 architecture with a differing dynamic >> linker path > >These are essentially the same suggestion, and if there are enough
Right. However, my suggestion involves *reducing* the architecture baseline again to make it accessible to more real-existing systems. But that’s orthogonal from the rest. (In fact, we might even want to do that for both.) >Because legacy binaries already "know" that the backwards-compatible >architecture is labelled i386 and i?86-linux-gnu with its dynamic linker Oh, i?86-linux-gnu is a good point I had not considered. >architecture would need to have a new dpkg architecture name, multiarch >tuple, GNU tuple (i?86-linux-gnut64?) and canonical ELF linker path. Definitely (and let’s just use the multiarch path for the ELF linker). Bit of bikeshedding on the name, of course. timet64 (or a shortened version) is a possibility but I’d also want off_t to be 64 bit in it like the BSDs have been doing for decades, for example. Ideas welcome, but it’s not important upfront. >If the new architecture is fully co-installable and distinguishable via >ELF flags (like the way amd64, i386 and x32 are), then the procedure to It will unfortunately have to be more than just how these three differ. i386 is ELF32 (ELFCLASS32) with e_machine EM_386 and ELFOSABI_LINUX or possibly ELFOSABI_NONE(?). amd64 is ELF64 (ELFCLASS64) with e_machine EM_X86_64. x32 is ELF32 (ELFCLASS32) with e_machine EM_X86_64. The new architecture would also have to be ELFCLASS32 and EM_386. Maybe we can distinguish them using e_flags… using a new EI_OSABI or, worse, e_machine sounds bad. How do we distinguish arm, armel and armhf? They all use EM_ARM probably (armeb is probably distinguished via ELFDATA2MSB). >"crossgrade" core system packages to it. If it isn't distinguishable by >ELF flags (so the dynamic linker would attempt to load i386t64 libraries >into an i386 process or vice versa, and sometimes crash as a result) I would like for things to be coïnstallable, of course. But why would the dynamic linker attempt to load the respective foreign libraries… oh right, not all are in the M-A path yet (on my box, they are, but legacy i386 systems would not have that). So we need a way to distinguish them in the ELF header and possibly also patch the i386 loader to check the new bit? field? note? and not load the solib if set. We’ll also need a cpp define, like we have… #if defined(__amd64__) && defined(__ILP32__) // x32 #if defined(__amd64__) && !defined(__ILP32__) // amd64 … and 「echo | gcc -m32 -E -dD - | less」 does not yet have anything suitable. Either patch it into gcc… (I’ve patched gcc/config/**.h files before) or… apparently, /usr/include/stdc-predef.h is included by recent GCC, if that were in the M-A path it might work. Is there any cross-distro effort for such a thing that we’d need to coordinate with? >(It's perhaps also worth noting that it's possible to upgrade from >i386 to amd64 without a net increase in e-waste by switching from i386 >hardware to older amd64 hardware that has already been discarded by its >original owner: I'm typing this into a second-hand ex-corporate Lenovo >T480s, built in 2018 according to its serial number label, and the X220 >that was previously very popular with DDs was a UEFI-capable amd64 from >around 2012.) Right, that’s possible for part of the use cases, and not a bad idea anyway. (Radical idea: application and framework developers ought to still test their things on low-spec machines, to get a feeling for just how much bloat they introduce…) bye, //mirabilos -- <cnuke> den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt… oder netzteile, an die man auch den monitor angeschlossen hat und die dann für ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder LAN party │ <nvb> damals, als der pizzateig noch auf dem monior "gegangen" ist
