[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170531131150.GH1627@brightrain.aerifal.cx>
Date: Wed, 31 May 2017 09:11:50 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: microMIPS32R2 O32 port
On Sat, May 27, 2017 at 10:00:57PM -0400, Rich Felker wrote:
> 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.
OK. The only question I have is why the syscall_cp.s portion is needed
at this stage. As long as all .s files are built as plain mips still
(with support for building them as micromips to come in the future) it
looks like this change belongs as part of that future patch.
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.
