Re: Spinlocks and compiler/memory barriers

On Tue, Jul 1, 2014 at 12:46 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> A few years back I ported the postresql client libraries and a few
> other pieces of software (in particular subversion) to a lot of
> obscure platforms (old sparc, hpux, irix, older aix, etc etc).
> Getting a modern gcc working on those platforms (with the possible
> exception of aix) is in many cases difficult or impossible. So
> requiring new gcc is exactly equivalent to desupporting.

I took a look around to see which operating systems support which
hardware platforms. It's a little hard to tell who is supporting
which operating systems, because the terminology is different on
different project web sites, and it's hard to tell which things are
actually ARMv5, as opposed to something else. But it seems that
NetBSD is has by far the largest list of supported platforms, and it
appears that they compile their current releases with either gcc 4.5
or gcc 4.8, depending on the particular port:

http://www.netbsd.org/developers/features/

According to http://www.netbsd.org/ports/ the ports that run on some
form of ARM are acorn26, acorn32, cats, epoc32, evbarm, hpcarm,
iyonix, netwinder, shark, and zaurus. epoc32 is not listed at all on
the features link above, but the others are all listed as using gcc
4.8.x. Even if they were using gcc 4.5.x, though, that would be good
enough, and most platforms that are now on 4.8.x were on 4.5.x before
the 4.8.x import got done:

http://mail-index.netbsd.org/tech-userlevel/2014/02/18/msg008484.html

Apparently, the last holdout preventing removal of gcc 4.1.x from
NetBSD was the vax port, which has happily now been upgraded to 4.8.x.

Debian also supports ARMv5; actually, they support ARMv4t and higher:

https://wiki.debian.org/ArmEabiPort

Debian has shipped a sufficiently-new compiler for our purposes since
6.0 (squeeze), released in 2009:

https://packages.debian.org/squeeze/gcc

So it's clearly *possible* to get newer gcc versions running on ARMv5.
I will grant you that it may not be the easiest thing to do on an
existing installation. But I don't think having us continue to ship
either known-broken code or completely-untested code is any better.
If someone needs to get PostgreSQL 9.5 running on ARMv5 using an older
gcc, they can test Andres's already-posted patch and, if it works, we
can commit it. What I think doesn't make sense is to ship it untested
and claim we have support when that really might or might not be true.

Also, none of this would affect the PostgreSQL client libraries that
you are talking about. s_lock.h is only used by the backend.

The bottom line is that I love supporting obscure platforms as much as
anyone here, and several other committers are already telling me that
I love it too much. We've got to draw the line somewhere, and I think
refusing to ship newly-written code that we have exactly zero means of
testing is a pretty good place to draw it.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company