Power8 asm code crashes older PPC Apple G5

[kencu]

When building openssl on a Dual G5 Mac, the included assembly code pulls in some Power8 specific code that crashes the DualG5 (which I believe is a modified Power4). Here's a link to the exact crash details https://trac.macports.org/ticket/53885.

I'm wondering if there is a way to include all the "good" assembly code but leave out the Power8 specific parts. Presently it looks like all or nothing when it comes to the asm code, but there may be a flag to disable the Power8-specific parts?

@dot-asm has been doing most of this work, I note. Thanks.

[grooverdan]

while vcipher is P8 specific this part of the code is called from https://github.com/openssl/openssl/blob/master/crypto/ppccap.c#L314 (consistent with the backtrace) which is it meant to trap the illegal instruction. Any clues as to why that doesn't happen on DualG5?

[kencu]

Excuse my obvious lack of expertise -- it looks like that bit of code probes for Altivec (which it will find on a DualG5), and if found, then probes for crypto207 by calling vcipher, which crashes with an illegal instruction call. Seems like it shouldn't call vcipher at all on a DualG5, or at least test for it in some way that doesn't crash.

With my current skill level, I could patch out that bit of code in the Macports build portfile quite easily, of course. But that seems inelegant.

[kencu]

I see also http://debian-bugs-dist.debian.narkive.com/v8Mg4FBh/bug-788720-openssl-illegal-instruction-in-openssl-crypto207-probe-on-powerpc which suggests the illegal instruction error is just normal testing behaviour, at least on debian...but it comes up as a reported crash on the DualG5. Is this crash something that can just be ignored?

[dot-asm]

It's actually FAQ, https://www.openssl.org/docs/faq.html#PROG17. It's not like we are total strangers to MacOS X for PPC, and do occasionally test it. In other words I can confirm that this is something that observed only under debugger. FAQ suggests two workarounds, but second doesn't seem to work on MacOS X. [Apple has to be always special, doesn't it?]

One can argue that there are no Power8-based MacOS X systems and there never will be one, and hence the code in question should not be there. Yes, but it's conscious choice to keep it. Rationale is to let users tolerate some redundant code at cost of possibility for us to maintain it in most platform-neutral way possible, or in other words treat all PowerPC-based systems as equal as possible. In practical terms less #ifdef [or whatever code] spaghetti is better.

Having said that, even if we choose to venture into omitting code in question specifically on MacOS X, keep in mind that omitting Power8-specific code won't be sufficient, because it's still interesting to run OPENSSL_ppc64_probe and it's going to fail on G4. You have to look beyond your computer :-)

[dot-asm]

treat all PowerPC-based systems as equal as possible.

Well, it's not like it always plays out. Most notably there is AIX-specific code in ppccap.c....

[kencu]

Thanks - sorry I missed the FAQ entry. MacPorts spins off a tcl shell to build certain ports, and if that shell calls svn the probe brings down the shell and the install aborts. So I'll figure something out.

I could patch the code myself without much trouble, perhaps even after testing the HW capability in the macports portfile to decide what to patch - but is there a capability environment variable I could set to avoid the probe more easily? I see PPC_CRYPTO207 and PPC_MADD300 (both of which are not present on G4 or G5) and then like you say, others like altivec and 64 bit that are present on some processors. I just don't quite see how to set those to avoid the probes at this moment.

[dot-asm]

I don't follow. Assertion is that bad thing happens only in debugger, but if application code is simply executed, then probes should remain transparent, because SIGILL signal is handled. [And my experience doesn't contradict this.] But nothing from above description sounds like code executed under debugger. And if it's not, then how can it be explained... Well, it might be some interaction between [shared?] libraries or maybe inter-language RTL problems (if there is Objective C involved in application OpenSSL is linked with)?

Meanwhile, as discussed in FAQ, you should be able to set environment variable to bypass detection altogether. In this case it OPENSSL_ppccap, and setting it to 0 is safe bet [at least as temporary measure].

[kencu]

There appear to be differences between MacOS versions - 10.5PPC runs the crypto207 probe code silently, and the bad instruction error is only noted when in the debugger, which is standard expected behaviour I see.

on 10.4PPC, it works differently. the crypto207 probe code pops up a dialog box indicating an execution error, and writes a backtrace and debugging info into CrashReporter for a 'bad instruction' error. I suspect this behaviour is not correct based on this discussion, and it was "fixed" in OS 10.5.

So it looks like this "error" can either just be ignored (and wipe out all the erroneous error logs on 10.4 from time to time) or I could patch the probe out on 10.4 if I really wanted to. 10.4 is ancient, and not many of us left even try to run it, so not worth more time from you I would say. Thanks for helping me understand what's going on.

[dot-asm]

it's still interesting to run OPENSSL_ppc64_probe

It occurred to me that this is a bit more nuanced. The subroutine that benefits from this probe is actually removed from master branch. But it is present in 1.1.0 and 1.0.2. Or in other words the probe is not as interesting in master.

on 10.4PPC, it works differently. the crypto207 probe code pops up a dialog box

I can't confirm this on G4 running 10.4.11. Though keep in mind that G4 is 32-bit processor, i.e. 32-bit build is my only option and SIGILL gets handled, so it might turn out that only 64-bit applications suffer from this. In either case, if one chooses to do something about it, sysctlbyname(3) seems to be the answer... As in #3101...

[noloader]

@dot-asm,

Myself and a fellow named Uri (@mouse07410) have experienced unexplained behavior after executing SIGILL probes on x86_64 OS X. Its a different project and different architecture, but the symptom/results sound very similar.

I have a G5 for testing, but the other project does not perform the CPU probing on it, so I've never experienced an issue.

Apple is not exactly known for high quality software or rigorus QA. I'm wondering if Apple's gear is just broken in this area.