From: Tom Lane <tgl@sss.pgh.pa.us>
To: YunQiang Su <wzssyqa@gmail.com>
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15844: MIPS: remove .set mips2 in s_lock.h to fix r6 build
In-reply-to: 
 <CAKcpw6XYkD9Ku-0Fw6VZ6=wR030c5xCBOnTGsjLzFqdffkM8dw@mail.gmail.com>
References: <15844-8f62fe7e163939b3@postgresql.org>
 <15052.1560455595@sss.pgh.pa.us>
 <CAKcpw6W2WBdTVnJSeV845V78bwOPDjhROfteX7D2o0TTU2_opA@mail.gmail.com>
 <23287.1560655935@sss.pgh.pa.us>
 <CAKcpw6W8Y56cxKJna6EsA+j2ZQ1p6DeXwMJFOOjb=baPigbV+Q@mail.gmail.com>
 <25321.1560659282@sss.pgh.pa.us>
 <CAKcpw6XYkD9Ku-0Fw6VZ6=wR030c5xCBOnTGsjLzFqdffkM8dw@mail.gmail.com>
Comments: In-reply-to YunQiang Su <wzssyqa@gmail.com>
	message dated "Sun, 16 Jun 2019 12:38:05 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <22614.1560701813.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sun, 16 Jun 2019 12:16:53 -0400
Message-ID: <22615.1560701813@sss.pgh.pa.us>
Precedence: bulk

YunQiang Su <wzssyqa@gmail.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> =E4=BA=8E2019=E5=B9=B46=E6=9C=8816=E6=97=A5=
=E5=91=A8=E6=97=A5 =E4=B8=8B=E5=8D=8812:28=E5=86=99=E9=81=93=EF=BC=9A
>> I found that specifying -march=3Dmips2 gets it to accept the s_lock.h
>> code without ".set mips2".  Given that we don't make any pretense of
>> actually running on MIPS-I hardware, I wonder if some hack involving
>> forcing -march would be sane?  You'd get better code quality across
>> the board, presumably.

> -march is not a good idea, since r6 cannot compatible with the previous =
version.
> If you use -march=3Dmips2 or something else, it will failed to build for=
 r6.
> Which -march to use should be determined by finial user or distribution =
vendor.

Sure, the trick would be to not override a (default or specified)
architecture setting that's higher than mips2.  I was imagining
using AC_EGREP_CPP() to see if __mips expands to exactly 1.  But
on reflection, probably a better idea is to just see if asm with
ll/sc/sync compiles, and add -march=3Dmips2 if not.

(We should not do anything if --disable-spinlocks has been specified,
btw, since then we don't need those asm commands to work.  This is
and would remain the workaround for building PG for MIPS-I, if some
benighted soul insists on doing that.)

>> (BTW, have you got any recommendations for booting recent Debian/MIPS
>> under qemu?  I can't get anything newer than wheezy to work.)

> I have an r6 one:
>   http://mips64el.bfsu.edu.cn/debian-new/tarball/qemu/
> It is buster.

Thanks for the pointer.

			regards, tom lane