From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11361 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [MUSL] microMIPS32R2 O32 port Date: Sat, 27 May 2017 22:00:57 -0400 Message-ID: <20170528020057.GD1627@brightrain.aerifal.cx> References: <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 X-Trace: blaine.gmane.org 1495936870 28026 195.159.176.226 (28 May 2017 02:01:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 28 May 2017 02:01:10 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11376-gllmg-musl=m.gmane.org@lists.openwall.com Sun May 28 04:01: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 1dEnVx-00079R-J9 for gllmg-musl@m.gmane.org; Sun, 28 May 2017 04:01:05 +0200 Original-Received: (qmail 18400 invoked by uid 550); 28 May 2017 02:01:09 -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 18382 invoked from network); 28 May 2017 02:01:08 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11361 Archived-At: On Fri, May 26, 2017 at 03:46:49AM +0000, Jaydeep Patil wrote: > Hi Rich, > > Could you please find some time to review this? I'm trying to catch up now. Sorry I've been behind on this. Rich > >-----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 >= (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 possible. > >>>> > >>>> 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