From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11294 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [MUSL] microMIPS32R2 O32 port Date: Tue, 25 Apr 2017 12:52:45 -0400 Message-ID: <20170425165245.GW17319@brightrain.aerifal.cx> References: <20170412192535.GG2082@port70.net> <20170412202721.GY17319@brightrain.aerifal.cx> <20170413090036.GH2082@port70.net> <20170421133300.GE17319@brightrain.aerifal.cx> <20170424134808.GQ17319@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 1493139187 24925 195.159.176.226 (25 Apr 2017 16:53:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Apr 2017 16:53:07 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Szabolcs Nagy , "musl@lists.openwall.com" , Andre McCurdy To: Jaydeep Patil Original-X-From: musl-return-11309-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 25 18:53:02 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 1d33i1-0006Kx-Fz for gllmg-musl@m.gmane.org; Tue, 25 Apr 2017 18:53:01 +0200 Original-Received: (qmail 13738 invoked by uid 550); 25 Apr 2017 16:53:05 -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 13712 invoked from network); 25 Apr 2017 16:53:03 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11294 Archived-At: 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? Rich