[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170528020057.GD1627@brightrain.aerifal.cx>
Date: Sat, 27 May 2017 22:00:57 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: microMIPS32R2 O32 port
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@...tec.com]
> >Sent: 11 May 2017 AM 08:56
> >To: musl@...ts.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@...tec.com]
> >>Sent: 26 April 2017 PM 12:44
> >>To: Rich Felker
> >>Cc: Szabolcs Nagy; musl@...ts.openwall.com; Andre McCurdy
> >>Subject: RE: [musl] [MUSL] 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
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.
