On Mon, Dec 13, 2021 at 8:05 PM Vagrant Cascadian
<vagr...@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
