core dump on ppc target

[th0ma7]

I am part of the group of maintainer of the SynoCommunity which maintains open source project for various Synology NAS versions and architectures. Recently we've updated our openssl version to 3.x part of python 3.11. This in turn also allowed migrated to rust based cryptography python wheel.

Problem: On ppc architecture only, for python applications making use of rust-based wheels it core dumps when loading PYO3 rust binding for python.

Questions are:

1. How can I debug this further to figure out what caused the issue? ref: Unable to start HomeAssistant Core on DS213+ SynoCommunity/spksrc#5684 (comment)
2. wondering if the issue could be due to tier 2 target being used powerpc-unknown-linux-gnu and if building a tier 3 powerpc-unknown-linux-gnuspe or specific powerpc-e500v2-linux-gnuspe using C libs may be what's really needed?

[adamreichold]

I think the observation that SIGILL is raised does indeed point at target selection as the issue, so building for a different target would be my first try. (I am not knowledgable on the PowerPC targets relevant for Synology hardware tough.)

Furthermore, I doubt the specific code in question is the culprit, it is just the first code triggering the issue because it is highly generic and invoked almost every time Rust and Python code interact. Hence, I would also suggest reduce the amount of moving parts by just trying one of the example extensions available in our repository, e.g. https://github.com/PyO3/pyo3/tree/main/examples/setuptools-rust-starter, instead of cryptography itself.

Personally, I had issues mixing Rust and C code on a 32-bit PowerPC platform (Cisco hardware, not Synology tough) due to incompatible implementations of the relevant calling conventions between Rust and GCC. This has been fixed in the mean time, but back then switching to Clang on the C side was a viable workaround.

[adamreichold]

I think the observation that SIGILL is raised does indeed point at target selection as the issue,

It might also that -Ctarget-cpu=... was used to select a specific CPU model within the powerpc-unknown-linux-gnu target but I would be surprised if that were the case.

[th0ma7]

@adamreichold thnx for your reply and hints provided

I think the observation that SIGILL is raised does indeed point at target selection as the issue, so building for a different target would be my first try. (I am not knowledgable on the PowerPC targets relevant for Synology hardware tough.)

That's also where I thought the issue may be. Although I haven't found yet a clear step-by-step guide on how to create my own target using Synology provided C libraries (and kernel source code if needed). On that I've also posted the following to the rust community https://users.rust-lang.org/t/step-by-step-howto-build-powerpc-e500v2-linux-gnuspe-arch/100646 in hope to find guidance for this in particular.

Furthermore, I doubt the specific code in question is the culprit, it is just the first code triggering the issue because it is highly generic and invoked almost every time Rust and Python code interact. Hence, I would also suggest reduce the amount of moving parts by just trying one of the example extensions available in our repository, e.g. https://github.com/PyO3/pyo3/tree/main/examples/setuptools-rust-starter, instead of cryptography itself.

That's something @hgy59 may be able to assist on? Will reach out to him and see if he has cycles to help out as I believe he's more knowledgeable than I on coding per say.

Personally, I personally had issues mixing Rust and C code on a 32-bit PowerPC platform (Cisco hardware, not Synology tough) due to incompatible implementations of the relevant calling conventions between Rust and GCC. This has been fixed in the mean time, but back then switching to Clang on the C side was a viable workaround.

Synology toolchain uses gcc only, further for this arch and DSM release a good old gcc-4.9.x and doesn't provide any Clang implementation. A much larger detour would be to build a x86_64 host Clang implementation for a powerpc-e500v2-linux-gnuspe target and see how things turns out... But that's a heck of a detour for a single arch out of the bunch... Further as Synology stopped supporting it since the DSM 7.x release.