RE: [MUSL] microMIPS32R2 O32 port

[Jaydeep Patil <Jaydeep.Patil@imgtec.com>]

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