Failure to pass structure to external function by value on PowerPC

[hhesse87]

We have a project which makes use of the grpcio crate and want to port this from amd64 to embedded armv7 and powerpc targets. Everythings works as expected on armv7 but we get segmentation faults when calling into gRPC on powerpc, both on the actual target as well as within QEMU.

We use the armv7-unknown-linux-gnuabihf and powerpc-unknown-linux-gnu targets of rust/LLVM and the compilers shipped as crossbuild-essential-{armhf,powerpc} in Debian Stretch to build the C code and link the final executable.

We have isolated the problem to passing a structure to an external function by value and have created the attached reproducer as a minimal example triggering the issue on powerpc but working correctly on amd64 and armv7. (The reproducer also fails when the C function is compiled using Clang 3.8 as shipped with Debian.)

reproducer.tar.gz

[ghost]

The reproducer also fails when the C function is compiled using Clang 3.8 as shipped with Debian.

Means compiled with Clang 3.8 instead of GCC for PowerPC as both GCC and Clang work on amd64 and armv7.

[adamreichold]

Should probably test this again now that #66050 has landed.

[workingjubilee]

I wonder if crossbuild on Debian Stretch was affected by them dropping support for PowerPC?
https://www.debian.org/releases/stretch/i386/ch02s01.html.en

If anyone has access to 32-bit PowerPC silicon, then it would be lovely to hear if this still reproduces or not.

[glaubitz]

Debian still supports PowerPC, just not through official releases: https://cdimage.debian.org/cdimage/ports/snapshots/2022-03-28/

Cross-builds still work, just make sure you use a current environment.

If you need access to big-endian PowerPC hardware, check out the GCC compile farm, see: https://gcc.gnu.org/wiki/CompileFarm

Disclaimer: I am one of the Debian Developers who maintains these unofficial ports.

[adamreichold]

I am not sure how conclusive this is, but I tried our old reproducer in a Debian 11 container running on OpenSUSE Tumbleweed. Everything works as expected on amd64 both on the host and in the container.

Using crossbuild-essential-powerpc and the nightly-2022-07-17 toolchain, building and running the binary via QEMU's user space emulation works, i.e

> CC=powerpc-linux-gnu-gcc CARGO_TARGET_POWERPC_UNKNOWN_LINUX_GNU_LINKER=powerpc-linux-gnu-gcc cargo build --target=powerpc-unknown-linux-gnu
[...]
> qemu-ppc -L/usr/powerpc-linux-gnu/ ./target/powerpc-unknown-linux-gnu/debug/reproduce 
x=7fffffff y=ffffffff

whereas using nightly-2018-09-13 leads to a segmentation fault:

# qemu-ppc -L /usr/powerpc-linux-gnu/ ./target/powerpc-unknown-linux-gnu/debug/reproducer
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)

As it looks like this is fixed and there is most likely nobody working on the original PowerPC-based project any more, I think this should be closed but I am admittedly unsure how reliable the user space emulation is.

[glaubitz]

FWIW, the rustc (currently 1.59.0 in Debian) package builds fine on Debian unstable on 32-bit PowerPC:

https://buildd.debian.org/status/fetch.php?pkg=rustc&arch=powerpc&ver=1.59.0%2Bdfsg1-2&stamp=1657851457&raw=0

[workingjubilee]

Debian still supports PowerPC, just not through official releases: https://cdimage.debian.org/cdimage/ports/snapshots/2022-03-28/

Cross-builds still work, just make sure you use a current environment.

If you need access to big-endian PowerPC hardware, check out the GCC compile farm, see: https://gcc.gnu.org/wiki/CompileFarm

Disclaimer: I am one of the Debian Developers who maintains these unofficial ports.

Oh okay! My mistake. Thank you for clarifying!

Hmm. The GCC Compile Farm appears to have only PowerPC 64-bit hosts (for both BE and LE) and no PowerPC 32-bit hosts, unless one of the chrp machines is one of those?

Given the Debian buildd logs suggest they were failing the rustc build at the time and it has now gone to passing, and QEMU also passes this now? If this needs to be reopened, it can be, but until then: I'm going to squint and call this close enough to resolved.