6 ms·

Fedora has been slowly removing i686: https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels https://fedoraproject.org/wiki/Changes/Stop_Building_i68

by rwmj 3y ago

Fedora has been slowly removing i686: https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Ke... https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemo... There's still some 32 bit software (usually proprietary stuff, and/or libraries used by Wine). Removing 32 bit libraries especially just breaks this software and you don't really have any option except to get the vendor to fix it. But more importantly I sometimes find 64 bit assumptions in code. One recent example was in this new package that we're trying to add to Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=2263333 https://bugzilla.redhat.com/show_bug.cgi?id=2263333 It doesn't compile on i686 with some obvious compile issues. Upstream isn't particularly interested in fixing them. Typically the issues are incorrect assumptions about the size of 'long' and 'size_t'. And incorrect casts from pointers to longs (instead of using uintptr_t). Does any of this matter still or should we embrace this 64 bit only world? Will CPU makers remove i686 support? I guess we're going to find out.

CJefferson 3y ago
It's increasingly hard to test 32 bits -- I run a modern Ubuntu, they don't even provide 32 bits versions of most libraries any more, so I have to wonder why it's worth putting significant hours I to supporting 32bits, when it's unclear if there are even any users.
- rwmj 3y ago
  I keep a very old Fedora VM around for this. Not ideal.
- torstenvl 3y ago
  How about effort to remove undefined behavior based on non-portable assumptions? No code should cast a pointer to a `long`, ever. Trying to excuse it it with "we don't support 32-bit" is deeply wrong. EDIT: Apparently this position is unpopular. I am curious why people feel differently.
  - CJefferson 3y ago
    Well, yes, I'd like to do that, but programmers make mistakes and it isn't easy to test. Also, you can't reasonably remove all undefined behaviour. In C++ you basically can't do file IO without undefined behaviour.
    - knorker 3y ago
      As a fellow UB nitpicker, I'd like to hear more about your favorite UB triggers. E.g. in the space of file IO.
      - CJefferson 3y ago
        The C++ filesystem section contains the following, which basically means you can’t do safe IO when other programs are running in the same computer: “ The behavior is undefined if the calls to functions in this library introduce a file system race, that is, when multiple threads, processes, or computers interleave access and modification to the same object in a file system.”
        torstenvl 3y ago
        I'm not sure that means much, since that's true of literally every language that does file I/O.
  - mark_undoio 3y ago
    On GCC , as far as I know, pointers will always cast to long and back ok. I'd expect the same from clang. No, that's not a portable behaviour but I can see that it's valid if you're targeting Linux. uintptr_t is more polite, though.
  - a1o 3y ago
    I agree with you, we have appropriate types now, so we don't need to use long anymore - long also has different assumptions in Windows x64 builds vs equivalent regular Linux x64 (see also LLP64 vs LP64 vs ILP64)
  - 3y ago
- ndiddy 3y ago
  Ubuntu dropped 32-bit support several years ago. AFAIK they only support the 32-bit libraries required by Steam and Wine.
jsheard 3y ago
> Does any of this matter still or should we embrace this 64 bit only world? Will CPU makers remove i686 support? I guess we're going to find out. We're already on this path, Intel has proposed an "X86-S" subset which drops support for booting into 16/32-bit modes (though 32-bit applications would still be supported under a 64-bit OS), ARM Cortex-A cores already dropped support for 32-bit boot a few years ago and the latest ones are also dropping support for 32-bit applications, so the whole stack has to be 64-bit. Apple preemptively killed 32-bit apps even on hardware that could technically still support them, and their current hardware doesn't support 32-bit at all, not even in Rosetta.
- my123 3y ago
  Rosetta supports 32-bit code execution via a very basic (segment-level) facility, designed for use by Wine.
  - jsheard 3y ago
    TIL. I'm surprised they went out of their way to accomodate emulating 32-bit Windows apps, when they cut off 32-bit Mac apps completely.
    - plorkyeran 3y ago
      Dropping 32-bit macOS apps let them drop the second copy of every system library, and possibly even more importantly, support for the old obj-c runtime that was weird and different from the runtime used on every other platform. Supporting 32-bit wine is a much smaller burden.
      - MBCook 3y ago
        Which is especially useful on phones that are much more memory constrained than desktops.
- zahllos 3y ago
  For the modern server/desktop and even laptop, that's also no bad thing. It is somewhat ridiculous that UEFI bioses, internally, still boot in 16-bit real mode and have to do all the steps your bios bootloader used to do to set up a 64-bit environment ready to go: https://github.com/tianocore/edk2/blob/edc6681206c1a8791981a2f911d2fb8b3d2f5768/UefiCpuPkg/ResetVector/Vtf0/Ia16/ResetVectorVtf0.asm https://github.com/tianocore/edk2/blob/edc6681206c1a8791981a..., https://github.com/tianocore/edk2/blob/edc6681206c1a8791981a2f911d2fb8b3d2f5768/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm https://github.com/tianocore/edk2/blob/edc6681206c1a8791981a..., https://github.com/tianocore/edk2/blob/edc6681206c1a8791981a2f911d2fb8b3d2f5768/UefiCpuPkg/ResetVector/Vtf0/Ia32/Flat32ToFlat64.asm https://github.com/tianocore/edk2/blob/edc6681206c1a8791981a... Why not just start the CPU in "long mode", which is what everyone is using it for, in the first place? These newer ARM processors support 32-bit code at EL0 only (userspace). That seems like a reasonable approach for x86 as well and the freebsd announcement has this to say: > There is currently no plan to remove support for 32-bit binaries on 64-bit kernels. So for the moment, you can run 32-bit applications just fine.
dooglius 3y ago
I thought the Linux kernel enforces/requires a pointer to fit into a long, so any platform with Linux will define long type as appropriately sized?
- DinoCoder99 3y ago
  I'd much prefer C users not use long at all. What's wrong with size_t and uint32_t and uint64_t?
  - UncleEntity 3y ago
    > What's wrong with size_t and uint32_t and uint64_t? An extra #include and more typing? Plus, all the C89 users are out of luck...
    - int_19h 3y ago
      It's trivial to roll your own basic <stdint.h> with those types for existing C89 implementations. Unless they don't provide the corresponding type natively at all (which can be the case for some 16-bit platforms and 64-bit). But then you have a bigger problem anyway.
    - legulere 3y ago
      Only with effort Linux was able to be ported to Clang. All compilers that compile Linux should also be able to deal with size_t and consorts.
    - deleted 3y ago
      [deleted]
cesarb 3y ago
> And incorrect casts from pointers to longs (instead of using uintptr_t). That's not an issue on mainstream Linux, since uintptr_t and long always have the same size, both on 32-bit and on 64-bit. It's an issue only when using some new experimental stuff which uses two machine words per pointer, or when trying to port to Windows (where long is always 32-bit even when compiling for 64-bit).
- Brian_K_White 3y ago
  At one point 16 bits were universal, and then 32 bits came along and broke everything. We learned some lessons that day. Then 32 bits was universal for a while and 64 bits came along and broke everything. I guess we forgot those lessons, but OK well at least we learned them again for real this time. What a relief it is that we have reached the final architecture and will never have to worry about anything like that again!
  - cesarb 3y ago
    > At one point 16 bits were universal, and then 32 bits came along and broke everything. That's not an issue in mainstream Linux, since 16-bit Linux (ELKS) never caught on. Other than ELKS and perhaps some new experimental stuff, since its first release Linux always had long and pointer with the same size.
  - arp242 3y ago
    At some point in history a "byte" could also be considered to mean any number of things. There was great value in standardizing on 8 bits. The there is of course no clean separation between the two, but by many definitions the "64-bit era" has already lasted longer than the "32-bit era". The real lesson from history is that we moved for specific practical reasons, and that these reasons don't exist with 64-bit architectures today. 64-bit is and most likely will remain the standard size for the foreseeable future. I predict that even embedded will (slowly) move to 64-bit because again, there is great value in standardizing these types of things.
    - int_19h 3y ago
cesarb 3y ago
> There's still some 32 bit software (usually proprietary stuff, and/or libraries used by Wine). Wine is going to stop being an issue somewhat soon. The Wine developers are adapting it to work more like Windows, by making even 32-bit applications call the 64-bit libraries. I expect that, not long after Wine switches to always using 64-bit libraries, distributions (probably starting with faster-moving ones like Fedora) will completely (or almost completely, leaving only glibc and its dependencies) drop the 32-bit libraries. And we're already close to the Y2038 deadline, which gives distributions another incentive to drop 32-bit libraries (instead of having to go through a migration to the 64-bit time API, similar to the migration to 64-bit file offsets we had some time ago).
- zozbot234 3y ago
  Debian is moving their 32-bit releases to 64-bit time, it's a big transition but it's expected to be ready for the next release. But they've also announced that they may be forced to drop their i686 release quite soon.

by rwmj 3y ago

CJefferson 3y ago

It's increasingly hard to test 32 bits -- I run a modern Ubuntu, they don't even provide 32 bits versions of most libraries any more, so I have to wonder why it's worth putting significant hours I to supporting 32bits, when it's unclear if there are even any users.

rwmj 3y ago
I keep a very old Fedora VM around for this. Not ideal.
torstenvl 3y ago
How about effort to remove undefined behavior based on non-portable assumptions? No code should cast a pointer to a `long`, ever. Trying to excuse it it with "we don't support 32-bit" is deeply wrong. EDIT: Apparently this position is unpopular. I am curious why people feel differently.
- CJefferson 3y ago
  Well, yes, I'd like to do that, but programmers make mistakes and it isn't easy to test. Also, you can't reasonably remove all undefined behaviour. In C++ you basically can't do file IO without undefined behaviour.
  - knorker 3y ago
    As a fellow UB nitpicker, I'd like to hear more about your favorite UB triggers. E.g. in the space of file IO.
    - CJefferson 3y ago
      The C++ filesystem section contains the following, which basically means you can’t do safe IO when other programs are running in the same computer: “ The behavior is undefined if the calls to functions in this library introduce a file system race, that is, when multiple threads, processes, or computers interleave access and modification to the same object in a file system.”
      - torstenvl 3y ago
        I'm not sure that means much, since that's true of literally every language that does file I/O.
- mark_undoio 3y ago
  On GCC , as far as I know, pointers will always cast to long and back ok. I'd expect the same from clang. No, that's not a portable behaviour but I can see that it's valid if you're targeting Linux. uintptr_t is more polite, though.
- a1o 3y ago
  I agree with you, we have appropriate types now, so we don't need to use long anymore - long also has different assumptions in Windows x64 builds vs equivalent regular Linux x64 (see also LLP64 vs LP64 vs ILP64)
- 3y ago
ndiddy 3y ago
Ubuntu dropped 32-bit support several years ago. AFAIK they only support the 32-bit libraries required by Steam and Wine.

jsheard 3y ago

> Does any of this matter still or should we embrace this 64 bit only world? Will CPU makers remove i686 support? I guess we're going to find out. We're already on this path, Intel has proposed an "X86-S" subset which drops support for booting into 16/32-bit modes (though 32-bit applications would still be supported under a 64-bit OS), ARM Cortex-A cores already dropped support for 32-bit boot a few years ago and the latest ones are also dropping support for 32-bit applications, so the whole stack has to be 64-bit. Apple preemptively killed 32-bit apps even on hardware that could technically still support them, and their current hardware doesn't support 32-bit at all, not even in Rosetta.

my123 3y ago
Rosetta supports 32-bit code execution via a very basic (segment-level) facility, designed for use by Wine.
- jsheard 3y ago
  TIL. I'm surprised they went out of their way to accomodate emulating 32-bit Windows apps, when they cut off 32-bit Mac apps completely.
  - plorkyeran 3y ago
    Dropping 32-bit macOS apps let them drop the second copy of every system library, and possibly even more importantly, support for the old obj-c runtime that was weird and different from the runtime used on every other platform. Supporting 32-bit wine is a much smaller burden.
    - MBCook 3y ago
      Which is especially useful on phones that are much more memory constrained than desktops.
zahllos 3y ago
For the modern server/desktop and even laptop, that's also no bad thing. It is somewhat ridiculous that UEFI bioses, internally, still boot in 16-bit real mode and have to do all the steps your bios bootloader used to do to set up a 64-bit environment ready to go: https://github.com/tianocore/edk2/blob/edc6681206c1a8791981a2f911d2fb8b3d2f5768/UefiCpuPkg/ResetVector/Vtf0/Ia16/ResetVectorVtf0.asm https://github.com/tianocore/edk2/blob/edc6681206c1a8791981a..., https://github.com/tianocore/edk2/blob/edc6681206c1a8791981a2f911d2fb8b3d2f5768/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm https://github.com/tianocore/edk2/blob/edc6681206c1a8791981a..., https://github.com/tianocore/edk2/blob/edc6681206c1a8791981a2f911d2fb8b3d2f5768/UefiCpuPkg/ResetVector/Vtf0/Ia32/Flat32ToFlat64.asm https://github.com/tianocore/edk2/blob/edc6681206c1a8791981a... Why not just start the CPU in "long mode", which is what everyone is using it for, in the first place? These newer ARM processors support 32-bit code at EL0 only (userspace). That seems like a reasonable approach for x86 as well and the freebsd announcement has this to say: > There is currently no plan to remove support for 32-bit binaries on 64-bit kernels. So for the moment, you can run 32-bit applications just fine.

dooglius 3y ago

I thought the Linux kernel enforces/requires a pointer to fit into a long, so any platform with Linux will define long type as appropriately sized?

DinoCoder99 3y ago
I'd much prefer C users not use long at all. What's wrong with size_t and uint32_t and uint64_t?
- UncleEntity 3y ago
  > What's wrong with size_t and uint32_t and uint64_t? An extra #include and more typing? Plus, all the C89 users are out of luck...
  - int_19h 3y ago
    It's trivial to roll your own basic <stdint.h> with those types for existing C89 implementations. Unless they don't provide the corresponding type natively at all (which can be the case for some 16-bit platforms and 64-bit). But then you have a bigger problem anyway.
  - legulere 3y ago
    Only with effort Linux was able to be ported to Clang. All compilers that compile Linux should also be able to deal with size_t and consorts.
  - deleted 3y ago
    [deleted]

cesarb 3y ago

> And incorrect casts from pointers to longs (instead of using uintptr_t). That's not an issue on mainstream Linux, since uintptr_t and long always have the same size, both on 32-bit and on 64-bit. It's an issue only when using some new experimental stuff which uses two machine words per pointer, or when trying to port to Windows (where long is always 32-bit even when compiling for 64-bit).

Brian_K_White 3y ago
At one point 16 bits were universal, and then 32 bits came along and broke everything. We learned some lessons that day. Then 32 bits was universal for a while and 64 bits came along and broke everything. I guess we forgot those lessons, but OK well at least we learned them again for real this time. What a relief it is that we have reached the final architecture and will never have to worry about anything like that again!
- cesarb 3y ago
  > At one point 16 bits were universal, and then 32 bits came along and broke everything. That's not an issue in mainstream Linux, since 16-bit Linux (ELKS) never caught on. Other than ELKS and perhaps some new experimental stuff, since its first release Linux always had long and pointer with the same size.
- arp242 3y ago
  At some point in history a "byte" could also be considered to mean any number of things. There was great value in standardizing on 8 bits. The there is of course no clean separation between the two, but by many definitions the "64-bit era" has already lasted longer than the "32-bit era". The real lesson from history is that we moved for specific practical reasons, and that these reasons don't exist with 64-bit architectures today. 64-bit is and most likely will remain the standard size for the foreseeable future. I predict that even embedded will (slowly) move to 64-bit because again, there is great value in standardizing these types of things.
  - int_19h 3y ago

cesarb 3y ago

> There's still some 32 bit software (usually proprietary stuff, and/or libraries used by Wine). Wine is going to stop being an issue somewhat soon. The Wine developers are adapting it to work more like Windows, by making even 32-bit applications call the 64-bit libraries. I expect that, not long after Wine switches to always using 64-bit libraries, distributions (probably starting with faster-moving ones like Fedora) will completely (or almost completely, leaving only glibc and its dependencies) drop the 32-bit libraries. And we're already close to the Y2038 deadline, which gives distributions another incentive to drop 32-bit libraries (instead of having to go through a migration to the 64-bit time API, similar to the migration to 64-bit file offsets we had some time ago).

zozbot234 3y ago
Debian is moving their 32-bit releases to 64-bit time, it's a big transition but it's expected to be ready for the next release. But they've also announced that they may be forced to drop their i686 release quite soon.