On Sun, Oct 2, 2022, at 1:59 PM, Adrian Bunk wrote:
> On Thu, Sep 29, 2022 at 10:53:21AM +0100, Wookey wrote:
>> On 2022-09-29 10:10 +0200, Arnd Bergmann wrote:
>>...
>> > I know are Alpine Linux, Adelie Linux and OpenWRT, but those all
>> > use musl-1.2, not glibc, and they have a much smaller set of packages.
>> 
>> OK. We still have plenty of bugs to find then :-)
>
> Such bugs have already been found, reported and fixed in Debian for
> 10 years thanks to the x32 port (e.g. #700012).
>
> More than 13k packages are currently Installed on x32 after having been 
> natively built and (if they have) passing their build time tests.

There is a minimal user base on x32, so I'm sure a lot of bugs
have gone unnoticed. Having 64-bit time_t on BSD and Windows
probably did more to find bugs, but there are still lots of
issues where neither of this would help. For instance:

- Any applications that use direct system calls with a 32-bit
  time_t have to change to the correct replacement syscall.
  This never had to be done on x32, because there is only one
  such set of syscalls. A number of upstream packages already
  got fixed for riscv32, but unfortunately some of those were
  done in a way that is still broken for architectures that
  have both the time32 and time64 versions.
  Most commonly, this affects __NR_futex/SYS_futex, but there
  are other syscalls needed elsewhere

- Libraries using input_event structures on /dev/input/*
  need to have an updated copy of the kernel headers. Most
  upstream packages do now, but I'm sure there are some left.

- Packages that rely on seccomp have to be updated to
  allow both the old and new versions of system calls in their
  whitelists

- Anything that is written in a language other than C but
  links to C libraries needs to be updated to use the new
  data structure definitions. Some of these may have a special
  case for x32, or they are just wrong. There are a lot of
  python or rust libraries affected by this, and no obvious
  answer.

- Things that are written in a language other than C/C++
  but don't link to C libraries should keep working, but
  will not be y2038 safe unless they also migrate to the
  time64 interfaces by copying what glibc did.

- Any package that currently relies on having a 32-bit
  off_t/ino_t will break after being forced to update to
  the 64-bit version, even if they don't care about
  time_t.

- Packages may hardcode the time_t/timeval/timespec
  definition. If they use __kernel_long_t, they would
  even work on x32, but break on any other 32-bit ABI.

      Arnd

Reply via email to