systemd reproducibility on armhf

[Vagrant Cascadian]

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?

Not sure exactly where this behavior comes from(quite possibly in a
dependent library and not systemd itself), but the build features should
be determined from the userland (armhf) that it is built in, and not
from which kernel is running.


Sorry I don't have more conclusive results, but at least this suggests a
direction to look into.


live well,
vagrant

[Arnd Bergmann]

On Mon, Dec 13, 2021 at 8:05 PM Vagrant Cascadian

Post by Vagrant Cascadian
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
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

[Michael Biebl]

Post by Arnd Bergmann
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.

If that was the case, should we see the same problem with an amd64
kernel and i386 userland?

[Arnd Bergmann]

Post by Michael Biebl

Post by Arnd Bergmann
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.

If that was the case, should we see the same problem with an amd64
kernel and i386 userland?

It depends on how it's written, they use different exceptions:

- you need normal fadvise64() on 64-bit
- you need fadvise64_64() on x86-32 and most other 32-bit platforms
- you need arm_fadvise64_64() on arm32 only

So anything that explicitly references arm_fadvise64_64() would have to
have a detection for building for 32-bit arm specifically, rather than just
detecting whether it's building for 32-bit or 64-bit.

Arnd