From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9312 Path: news.gmane.org!not-for-mail From: Jaydeep Patil Newsgroups: gmane.linux.lib.musl.general Subject: RE: Re: mips n64 porting review Date: Mon, 15 Feb 2016 04:46:47 +0000 Message-ID: References: <20160203233657.GL9349@brightrain.aerifal.cx> <20160204235246.GU9349@brightrain.aerifal.cx> <20160205042734.GV9349@brightrain.aerifal.cx> <20160212185115.GS9349@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1455545337 15558 80.91.229.3 (15 Feb 2016 14:08:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 15 Feb 2016 14:08:57 +0000 (UTC) Cc: Szabolcs Nagy , Anand Takale , "musl@lists.openwall.com" To: Rich Felker , Mahesh Bodapati Original-X-From: musl-return-9325-gllmg-musl=m.gmane.org@lists.openwall.com Mon Feb 15 15:08:55 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aVJpf-0008DZ-3T for gllmg-musl@m.gmane.org; Mon, 15 Feb 2016 15:08:55 +0100 Original-Received: (qmail 5239 invoked by uid 550); 15 Feb 2016 14:07:57 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 10106 invoked from network); 15 Feb 2016 04:47:04 -0000 Thread-Topic: [musl] Re: mips n64 porting review Thread-Index: AdFeaeZ1B6dgB7EOQy+UkcGmdsxnIwALGb1QAAXXhYAAMtgqgAAJmMEAAX40J4AAhMctUA== In-Reply-To: <20160212185115.GS9349@brightrain.aerifal.cx> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.93.60] Xref: news.gmane.org gmane.linux.lib.musl.general:9312 Archived-At: Hi Rich, Thanks for your comments. We are working on rebasing the patch.=20 Regards, Jaydeep -----Original Message----- From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker Sent: 13 February 2016 AM 12:21 To: Mahesh Bodapati Cc: Szabolcs Nagy; Jaydeep Patil; Anand Takale; musl@lists.openwall.com Subject: Re: [musl] Re: mips n64 porting review On Thu, Feb 04, 2016 at 11:27:34PM -0500, Rich Felker wrote: > On Thu, Feb 04, 2016 at 06:52:47PM -0500, Rich Felker wrote: > > On Wed, Feb 03, 2016 at 06:36:57PM -0500, Rich Felker wrote: > > > On Wed, Feb 03, 2016 at 03:41:13PM +0000, Mahesh Bodapati wrote: > > > > Hi Rich, > > > > I have attached the patch which has all the MIPS n64 porting=20 > > > > work. I have created mips64port remote branch on GitHub and the=20 > > > > repository is=20 > > > > https://github.com/MaheshBodapati/musl/tree/mips64port which has=20 > > > > the broken down patches and the base revision on which I have prepa= red patch is v1.1.12-41-g3abb094. > > >=20 > > > Some preliminary review: > >=20 > > One more thing that came up in reviewing syscall_cp.s was actually a=20 > > bug copied from existing code in musl, which is fixed by this commit: > >=20 > > http://git.musl-libc.org/cgit/musl/commit/?id=3D756c8af8589265e99e454f > > e3adcda1d0bc5e1963 > >=20 > > In practice the code seemed to work but it was wrong with respect to=20 > > ABI requirements. > >=20 > > I think the way you're saving $gp on the stack in sigsetjmp.s is=20 > > also invalid since that part of the stack will have been clobbered=20 > > by the time setjmp returns a second time. You could save it inside=20 > > an unused part of the jump buffer, but it might be better to just=20 > > avoid the $gp register and instead use temp registers and possibly=20 > > some pc-relative address computations. >=20 > Likewise in pipe.s, it's overly complicated by the fact that it's=20 > saving $gp on the stack and thereby can't make a tail call to=20 > __syscall_ret like it's intended to. If you just use a different=20 > register instead of $gp that's call-clobbered you can tail-call just=20 > like the 32-bit mips version. Alternatively it's possible now to write=20 > src/unistd/mips64/pipe.c instead using inline asm and let the compiler=20 > handle the nastiness of the calling convention. I'd be happy with=20 > either approach; the C version is probably mildly nicer, especially if=20 > the compiler still does the tail-call right and doesn't generate come=20 > bloated monstrosity. (Note that you can't use C for sigsetjmp though=20 > because it can't use the stack.) >=20 > At this point I think I've looked through all the mips64 files at=20 > least once and caught all the important issues. Ping. Any questions or updates on mips64? Rich