Re: BUG #15844: MIPS: remove .set mips2 in s_lock.h to fix r6 build
От | YunQiang Su |
---|---|
Тема | Re: BUG #15844: MIPS: remove .set mips2 in s_lock.h to fix r6 build |
Дата | |
Msg-id | CAKcpw6W2WBdTVnJSeV845V78bwOPDjhROfteX7D2o0TTU2_opA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #15844: MIPS: remove .set mips2 in s_lock.h to fix r6 build (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #15844: MIPS: remove .set mips2 in s_lock.h to fix r6 build
|
Список | pgsql-bugs |
Tom Lane <tgl@sss.pgh.pa.us> 于2019年6月14日周五 上午3:53写道: > > PG Bug reporting form <noreply@postgresql.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 binary now. While, as I know that we are using gcc to call `as', it won't be a problem anymore. Since no body set the default target of gcc as MIPS I nowdays. > > regards, tom lane -- YunQiang Su
В списке pgsql-bugs по дате отправления: