From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11287 Path: news.gmane.org!.POSTED!not-for-mail From: Jaydeep Patil Newsgroups: gmane.linux.lib.musl.general Subject: RE: [MUSL] microMIPS32R2 O32 port Date: Tue, 25 Apr 2017 04:45:29 +0000 Message-ID: References: <20170407141941.GQ17319@brightrain.aerifal.cx> <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" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1493095549 24631 195.159.176.226 (25 Apr 2017 04:45:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Apr 2017 04:45:49 +0000 (UTC) Cc: Szabolcs Nagy , "musl@lists.openwall.com" , Andre McCurdy To: Rich Felker Original-X-From: musl-return-11302-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 25 06:45:44 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 1d2sMA-0006FP-8h for gllmg-musl@m.gmane.org; Tue, 25 Apr 2017 06:45:42 +0200 Original-Received: (qmail 11927 invoked by uid 550); 25 Apr 2017 04:45:46 -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 11906 invoked from network); 25 Apr 2017 04:45:45 -0000 Thread-Topic: [musl] [MUSL] microMIPS32R2 O32 port Thread-Index: AdKt1iVvBw5zYQz8QaWQDACqF692CAA7R8oAACltEkAABLsbgAEB0oLgAARReIAAAig8gAACyxwAABlXkqD///FggP//iRXwgA1VrAD/+4O24IAJN4MA//61n8A= In-Reply-To: <20170424134808.GQ17319@brightrain.aerifal.cx> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.93.60] Xref: news.gmane.org gmane.linux.lib.musl.general:11287 Archived-At: >-----Original Message----- >From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker >Sent: 24 April 2017 PM 07:18 >To: Jaydeep Patil >Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy >Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port > >On Mon, Apr 24, 2017 at 05:30:34AM +0000, Jaydeep Patil wrote: >> >-----Original Message----- >> >From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker >> >Sent: 21 April 2017 PM 07:03 >> >To: Jaydeep Patil >> >Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy >> >Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port >> > >> >On Thu, Apr 13, 2017 at 10:37:05AM +0000, Jaydeep Patil wrote: >> >> Hi Szabolcs, >> >> >> >> Please find the attached patch. >> > >> >I still don't follow the motivation of all the changes in this patch. >> >See comments below: >> > >> >> [...] >> >> diff --git a/arch/mips/crt_arch.h b/arch/mips/crt_arch.h index >> >> 9fc50d7..78832b0 100644 >> >> --- a/arch/mips/crt_arch.h >> >> +++ b/arch/mips/crt_arch.h >> >> @@ -1,6 +1,7 @@ >> >> __asm__( >> >> ".set push\n" >> >> ".set noreorder\n" >> >> +".set nomicromips\n" >> >> ".text \n" >> >> ".global _" START "\n" >> >> ".global " START "\n" >> > >> >Is there a need for crt1.o (or other users of this file like >> >dlstart/rcrt1) to be built as plain mips rather than micromips? If >> >so, please explain. Arbitrary changes like this without an >> >explanation of why they're being made (what was broken before, and >> >why this is the correct fix) are not acceptable. >> >> The crt1.o and __cp_begin are built as pure MIPS functions rather than >> microMIPS as they are reading data using $ra register (with ISA bit >> set). We can clear the ISA bit (using INS) and choose to compile these >> functions as microMIPS. > >I see. So all the .s files are assembled as plain (32-bit) MIPS, and these= files are >just affected because the asm is included in .c files that might be compil= ed in >microMIPS mode. That makes sense. I think it's probably just better to mak= e >the code microMIPS-compatible though by clearing the low bits.=20 Ok, I will remove the "nomicromips" restriction and clear the ISA bit inst= ead. > 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. >> >> diff --git a/arch/mips/reloc.h b/arch/mips/reloc.h index >> >> b3d59a4..772b3aa 100644 >> >> --- a/arch/mips/reloc.h >> >> +++ b/arch/mips/reloc.h >> >> @@ -36,15 +36,23 @@ >> >> #define CRTJMP(pc,sp) __asm__ __volatile__( \ >> >> "move $sp,%1 ; jr %0" : : "r"(pc), "r"(sp) : "memory" ) >> >> >> >> +/* >> >> + * When compiled for microMIPS, .align makes sure that .gpword >> >> + * is placed at word boundary. $ra must point to first .gpword. >> >> + * ISA bit of $ra must be cleared for microMIPS before using it >> >> + * as a base address. For MIPS, ISA bit is always zero. >> >> +*/ >> >> #define GETFUNCSYM(fp, sym, got) __asm__ ( \ >> >> ".hidden " #sym "\n" \ >> >> ".set push \n" \ >> >> ".set noreorder \n" \ >> >> + " .align 2 \n" \ >> >> " bal 1f \n" \ >> >> " nop \n" \ >> >> " .gpword . \n" \ >> >> " .gpword " #sym " \n" \ >> >> - "1: lw %0, ($ra) \n" \ >> >> + "1: ins $ra, $0, 0, 1 \n" \ >> >> + " lw %0, ($ra) \n" \ >> >> " subu %0, $ra, %0 \n" \ >> >> " lw $ra, 4($ra) \n" \ >> >> " addu %0, %0, $ra \n" \ >> > >> >By this, do you mean that .gpword is producing a value that's >> >relative to the actual byte position of the directive rather than the >> >logical (ISA bit set) value of "." at the point of .gpword? >> >> ISA bit is set for all microMIPS symbols (including the dot symbol). >> The GETFUNCSYM macro cannot be compiled as pure MIPS code as it might >> be expanded in a microMIPS function. We need to clear the ISA bit of >> $ra before using it as a base address in load/store instructions. > >OK. And the same appproach would work for crt_arch.h and other places, >right? Yes. >> >> 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 fi= les >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 t= hat >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. Thanks, Jaydeep