|From:||YunQiang Su <wzssyqa(at)gmail(dot)com>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Subject:||Re: BUG #15844: MIPS: remove .set mips2 in s_lock.h to fix r6 build|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 于2019年6月14日周五 上午3:53写道：
> PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> > MIPS r6 changes the encoding of LL/SC instruction,
> > while the .set mips2 will force assembler to generate
> > old encoding.
> > ...
> > In fact if we not willing to support MIPS I or any CPU without ll/sc
> > at all, we can just remove .set mips2 here.
> After further digging around, I'm liking the alternative of just
> removing the ".set mips2" lines. MIPS-I has been obsolete since 1989,
> and the MIPS-II instruction set has a lot of other substantial advantages
> over MIPS-I besides having LL/SC, so it's pretty hard to believe that
> anyone is still using toolchains that default to assuming MIPS-I
> instruction set.
You are right. I have no idea anyone is using MIPS I.
> Digging around in our archives, it looks like ".set mips2" was required
> when it was added, but that was on the strength of testing with a
> machine running Linux 2.4.27-r5k-cobalt. We need to research when/if
> Linux changed their default configuration.
It depends on the options to `as'.
If we build `as' without any option, and call it directly, it still
generate MIPS I
While, as I know that we are using gcc to call `as', it won't be a
Since no body set the default target of gcc as MIPS I nowdays.
> regards, tom lane
|Next Message||Tom Lane||2019-06-16 03:32:15||Re: BUG #15844: MIPS: remove .set mips2 in s_lock.h to fix r6 build|
|Previous Message||YunQiang Su||2019-06-16 01:46:08||Re: BUG #15844: MIPS: remove .set mips2 in s_lock.h to fix r6 build|