[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <BD7773622145634B952E5B54ACA8E349E037259A@PUMAIL01.pu.imgtec.org>
Date: Thu, 1 Jun 2017 04:21:24 +0000
From: Jaydeep Patil <Jaydeep.Patil@...tec.com>
To: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: RE: microMIPS32R2 O32 port
Hi Rich,
In the previous version of this patch (micromips32r2_v2), I had suggested to build the .s files as pure MIPS code (using ".set nomicromips" directive).
However change in reloc.h is still required as it could be inlined in a micromips function.
Please refer to https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v2 instead.
Thanks,
Jaydeep
>-----Original Message-----
>From: Rich Felker [mailto:dalias@...ifal.cx] On Behalf Of Rich Felker
>Sent: 31 May 2017 PM 06:42
>To: musl@...ts.openwall.com
>Subject: Re: [musl] [MUSL] 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.
