YunQiang Su <wzssyqa@gmail.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> 于2019年6月16日周日 下午12:28写道：
>> I found that specifying -march=mips2 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=mips2 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=mips2 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