[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170425165245.GW17319@brightrain.aerifal.cx>
Date: Tue, 25 Apr 2017 12:52:45 -0400
From: Rich Felker <dalias@...c.org>
To: Jaydeep Patil <Jaydeep.Patil@...tec.com>
Cc: Szabolcs Nagy <nsz@...t70.net>,
"musl@...ts.openwall.com" <musl@...ts.openwall.com>,
Andre McCurdy <armccurdy@...il.com>
Subject: Re: 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?
Rich
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.
