[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: systemd reproducibility on armhf



On Mon, Dec 13, 2021 at 8:05 PM Vagrant Cascadian
<vagrant@reproducible-builds.org> wrote:
>
> I finally did a reprotest build of systemd on armhf to try and figure
> out why it doesn't build reproducibly... but it built reproducibly...
>
> My test did not test building with a 64-bit kernel (it was using a
> 32-bit kernel in both cases), whereas the tests.reproducible-builds.org
> infrastructure systematically tests one build with 64-bit kernel and one
> with a 32-bit kernel...
>
> The build done with a 32-bit kernel includes a reference to
> "arm_fadvise64_64", whereas the build with a 64-bit kernel does
> not:
>
>   https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/armhf/diffoscope-results/systemd.html
>
> Does fadvise (posix_fadvise?) on 64-bit not need any special handling,
> whereas on 32-bit needs a wrapper function of some kind?

There should not be any difference between which kernel you are running
on, but there is a difference in behavior between architectures you build for.

fadvise is a strange syscall, since it was introduced incorrectly
multiple times,
and depending on the architecture you have different levels of fallbacks:

- fadvise64 was meant as the generic syscall, but it only works right on 64-bit
  architectures, as the length argument is truncated to 4GB otherwise, and the
  'offset' may be passed in the wrong registers on certain 32-bit architectures
- fadvise64_64 was introduced to solve the problem with the length argument,
  but does not solve the other one
- arm_fadvise64_64 (and the same thing on i386, nds32, csky, sh and maybe more)
  deals with the problem of passing 64-bit arguments in pairs of registers, by
  reordering the arguments.

It sounds like there is a compile-time check in systemd that determines which
of these to use based on the host architecture, rather than the target
architecture.

        Arnd


Reply to: