Date: Wed, 26 Apr 2017 07:14:06 +0000 From: Jaydeep Patil <Jaydeep.Patil@...tec.com> To: Rich Felker <dalias@...c.org> CC: Szabolcs Nagy <nsz@...t70.net>, "musl@...ts.openwall.com" <musl@...ts.openwall.com>, Andre McCurdy <armccurdy@...il.com> Subject: RE: microMIPS32R2 O32 port >-----Original Message----- >From: Rich Felker [mailto:dalias@...ifal.cx] On Behalf Of Rich Felker >Sent: 25 April 2017 PM 10:23 >To: Jaydeep Patil >Cc: Szabolcs Nagy; musl@...ts.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 Download attachment "microMIPS_32R2_v3.patch" of type "application/octet-stream" (1866 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.