From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11351 Path: news.gmane.org!.POSTED!not-for-mail From: Jaydeep Patil Newsgroups: gmane.linux.lib.musl.general Subject: RE: [MUSL] microMIPS32R2 O32 port Date: Fri, 26 May 2017 03:46:49 +0000 Message-ID: References: <20170412192535.GG2082@port70.net> <20170412202721.GY17319@brightrain.aerifal.cx> <20170413090036.GH2082@port70.net> <20170421133300.GE17319@brightrain.aerifal.cx> <20170424134808.GQ17319@brightrain.aerifal.cx> <20170425165245.GW17319@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1495770430 13489 195.159.176.226 (26 May 2017 03:47:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 26 May 2017 03:47:10 +0000 (UTC) Cc: Szabolcs Nagy , Andre McCurdy To: "musl@lists.openwall.com" , Rich Felker Original-X-From: musl-return-11366-gllmg-musl=m.gmane.org@lists.openwall.com Fri May 26 05:47:05 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1dE6DP-0003MY-Rm for gllmg-musl@m.gmane.org; Fri, 26 May 2017 05:47:03 +0200 Original-Received: (qmail 1433 invoked by uid 550); 26 May 2017 03:47:06 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 1412 invoked from network); 26 May 2017 03:47:05 -0000 Thread-Topic: [musl] [MUSL] microMIPS32R2 O32 port Thread-Index: AdKt1iVvBw5zYQz8QaWQDACqF692CAA7R8oAACltEkAABLsbgAEB0oLgAARReIAAAig8gAACyxwAABlXkqD///FggP//iRXwgA1VrAD/+4O24IAJN4MA//61n8AAYglegP/+tFVQ/+YUh/D/tJARoA== In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.91.65] Xref: news.gmane.org gmane.linux.lib.musl.general:11351 Archived-At: Hi Rich, Could you please find some time to review this? Thanks, Jaydeep >-----Original Message----- >From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com] >Sent: 11 May 2017 AM 08:56 >To: musl@lists.openwall.com; Rich Felker >Cc: Szabolcs Nagy; Andre McCurdy >Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port > >Hi Rich, > >Could you please find some time to review >https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v3 branch? > >Thanks, >Jaydeep > >>-----Original Message----- >>From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com] >>Sent: 26 April 2017 PM 12:44 >>To: Rich Felker >>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy >>Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port >> >>>-----Original Message----- >>>From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker >>>Sent: 25 April 2017 PM 10:23 >>>To: Jaydeep Patil >>>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy >>>Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port >>> >>>On Tue, Apr 25, 2017 at 04:45:29AM +0000, Jaydeep Patil wrote: >>>> > But syscall_cp.s needs some care because saved instruction pointer >>>> >values are compared against these labels. In micromips mode, do the >>>> >labels evaluate with the +1 low bit offset? >>>> >>>> Yes, in microMIPS mode, ISA bit (0th bit) is set for labels. However >>>> I don't see any issue with following comparison >>>> >>>> pc >=3D (uintptr_t)__cp_begin && pc < (uintptr_t)__cp_end >>>> >>>> The ISA bit will be set even for PC in the saved context. >>> >>>Agreed, I think it should work as expected. >>> >>>> >> >> diff --git a/src/thread/mips/syscall_cp.s >>>> >> >> b/src/thread/mips/syscall_cp.s index d284626..9c5f55e 100644 >>>> >> >> --- a/src/thread/mips/syscall_cp.s >>>> >> >> +++ b/src/thread/mips/syscall_cp.s >>>> >> >> @@ -1,5 +1,5 @@ >>>> >> >> .set noreorder >>>> >> >> - >>>> >> >> +.set nomicromips >>>> >> >> .global __cp_begin >>>> >> >> .hidden __cp_begin >>>> >> >> .type __cp_begin,@function >>>> >> > >>>> >> >I'm also unclear on the motivation of this one. Before (v1) you >>>> >> >had a lot of changes to replace .s files with something >>>> >> >micromips-compatible (removing branch delay slots); now (v2) >>>> >> >those changes are not included. So are .s files even being built >>>> >> >as micromips at all? If not, why is the above needed? If so, how >>>> >> >do the files >>>> >with delay slots work? >>>> >> >>>> >> Branch delay slots are removed (called as compact instructions) >>>> >> in the newer MIPS/microMIPS cores (in development). >>>> >> The MIPS/microMIPS R2-R6 still support instructions with delay slot= . >>>> >> Assembler takes care of converting a BRANCH + NOP to its >>>> >> appropriate compact instruction (BEQ + NOP to BEQC). >>>> >> With the v1 branch I was trying to create generic hand-written >>>> >> assembly which can be used for newer cores with the compact >>>> >> instructions. >>>> >> However I realized that it would appropriate to create a new arch >>>> >> instead of creating generic assembly. >>>> >> Thus in v2 branch I modified only those functions which would >>>> >> create issues when compiled with interlinking on. >>>> > >>>> >Based on the discussions so far, I don't think pure-micromips >>>> >qualifies as a new arch. If it would be possible to take a program >>>> >compiled as micromips- only, and run it with the libc.so/ldso built >>>> >for plain mips on a machine that supports both forms of code, then >>>> >it's not a separate arch, and as I understand it this should be possi= ble. >>>> >>>> Yes, in the context of miroMIPSR2-R5, we don't need to create a new >arch. >>>> >>>> >Rich >>>> >>>> I will create v3 if you are OK with this approach. >>> >>>OK. Can you factor it as one patch that's the minimal needed to make >>>the .c files (including ones that include the crt_arch.h/reloc.h asm >>>code) build correctly in micromips mode, which should be quick to >>>review/accept, and a second (if you want to do this phase now; if not >>>you can leave it til later) that makes the .s files micromips-compatible= ? >> >>Please refer to https://github.com/JaydeepIMG/musl- >>1/tree/micromips32r2_v3 for changes (also attached as a patch). >>I will push a separate patch to make .s file microMIPS-only compatible. >> >>>Rich >> >>Thanks, >>Jaydeep