make-config.sh guesses ppc64 on ppc

[Thomas Fitzsimmons]

On my Debian big-endian ppc64 system, make.sh produces the following
error by default:

$ sh make.sh
[...]
cc -m32 -I../src/runtime where-is-mcontext.c -ldl -Wl,-no-as-needed -o where-is-mcontext
In file included from where-is-mcontext.c:21:
/usr/include/stdio.h:27:10: fatal error: bits/libc-header-start.h: No such file or directory
   27 | #include <bits/libc-header-start.h>
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [<builtin>: where-is-mcontext] Error 1
[...]
$

My system does not have 32-bit PowerPC development packages installed,
so -m32 is not supported.

"sh make.sh --arch=ppc64" works, but I think it probably makes sense
to have make-config.sh guess "ppc64" instead of "ppc" in this case.
The fact that it guesses "ppc" seems to be historical, considering the
commit was from 2006. Are there systems where a "ppc64" guess would
do the wrong thing?

[Douglas Katzman (dougk)]

I don't think we've blessed the ppc64 into official existence yet. The downloadable binaries don't have it, and the status page says that it's in progress.
We need to establish a matrix of known good configurations: what combinations of endian-ness, word size, and ABI versions are expected to work.

As far as I know, more tests pass for ppc32 big-endian than pass for ppc64 big-endian, so that situation would need to be corrected. (Lacking any historical data as to what passed on ppc 32-bit, I don't even know whether that's getting better or worse, but I have a feeling it's doing a little of both, as is ppc64)
I have heard anecdotal evidence that the ppc64 has some suboptimal compilation that may be considered a regression relative to ppc32; so if somebody does have 32-bit libraries installed, they may well prefer to build the 32-bit code.

That said, if the build machine fits into one of the known good configs for 64-bit, and can be auto-detected as such, and does NOT have 32-bit (like little-endian which never had a 32-bit ABI, or 64-bit which installed as yours lacks the requisite headers and libraries) then I'd say sure, switch it. But as of now, I think 32-bit is generally more stable.

[Thomas Fitzsimmons (fitzsim)]

Douglas Katzman <email address hidden> writes:

> I don't think we've blessed the ppc64 into official existence yet. The
> downloadable binaries don't have it, and the status page says that
> it's in progress.

Oh yeah, I hadn't checked that page in a while.

> We need to establish a matrix of known good configurations: what
> combinations of endian-ness, word size, and ABI versions are expected
> to work.

Makes sense. I can offer some opinions about the matrix specifically
for systems running the Linux kernel and the GNU C Library.

For 32-bit word size, I think the 32-bit PowerPC SBCL support is fine
as-is. As far as I know, no little endian ppc32 systems ever existed,
and there were no major ABI versions to choose from. (It might make
sense to upload current ppc binaries to the website, but I don't know
the criteria or procedures for doing so.)

For 64-bit PowerPC, this is the table I'm thinking of:

| Configuration | Existed | Distro | SBCL Support |
|----------------+---------+--------------+--------------|
| ppc64-le-abiv1 | Never | ;; | ;; |
| ppc64-be-abiv1 | YES | Debian/glibc | YES¹ |
| ppc64-le-abiv2 | YES | Debian/glibc | YES |
| ppc64-be-abiv2 | YES | Void/glibc² | DESIRED |

1. With the patches in bug 1900258 and bug 1900343, ppc test results [a]
   and ppc64 test results [b] seem pretty similar, so I optimistically
   put "YES" here instead of "DESIRED".

2. glibc has support for big-endian ABIv2 which Void-ppc enables.
   However, glibc does not officially support ABIv2 for big-endian
   because it is not backward compatible with ABIv1, which already
   existed for big-endian ppc64 before ABIv2 came out. From what I've
   seen on some IRC channels though, there's desire to use ABIv2 for
   big-endian, with Void-ppc being one example. I think SBCL should
   strive to work for that configuration.

SBCL currently uses big-endian and little-endian feature expressions
where it would probably be clearer to define abiv1 and abiv2 features
(some of the comments allude to this). Practically though,
little-endian implies ABIv2 and big-endian implies ABIv1. It would
probably be overkill, for instance, to make a new column on the status
page for PPC64-ABIv2.

> As far as I know, more tests pass for ppc32 big-endian than pass for
> ppc64 big-endian, so that situation would need to be corrected.
> (Lacking any historical data as to what passed on ppc 32-bit, I don't
> even know whether that's getting better or worse, but I have a feeling
> it's doing a little of both, as is ppc64)

I happened to run the ppc32 test suite on a Debian 10 virtual machine to
regression-test my second patch for bug 1900258; I attached the results
[a] of a test run on commit 514934074c1afa1d50a50f93091ffe8e0a0075b2
prior to applying my patches. I also attached ppc64 results [b] for
comparison.

> I have heard anecdotal evidence that the ppc64 has some suboptimal
> compilation that may be considered a regression relative to ppc32; so
> if somebody does have 32-bit libraries installed, they may well prefer
> to build the 32-bit code.

Hmm, OK, it'd be nice to have bugs filed for such regr...

[Thomas Fitzsimmons (fitzsim)]

I've been using "sh make.sh --arch=ppc64" and it works fine. I'm closing this bug report as "Opinion".