From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9380 Path: news.gmane.org!not-for-mail From: "dalias@libc.org" Newsgroups: gmane.linux.lib.musl.general Subject: Re: mips n64 porting review Date: Wed, 24 Feb 2016 12:53:12 -0500 Message-ID: <20160224175312.GS9349@brightrain.aerifal.cx> References: <20160223033233.GM9349@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1456336416 18776 80.91.229.3 (24 Feb 2016 17:53:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Feb 2016 17:53:36 +0000 (UTC) Cc: "musl@lists.openwall.com" , Mahesh Bodapati To: Jaydeep Patil Original-X-From: musl-return-9393-gllmg-musl=m.gmane.org@lists.openwall.com Wed Feb 24 18:53:33 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 1aYdcy-0000ra-Ev for gllmg-musl@m.gmane.org; Wed, 24 Feb 2016 18:53:32 +0100 Original-Received: (qmail 5457 invoked by uid 550); 24 Feb 2016 17:53:30 -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 5435 invoked from network); 24 Feb 2016 17:53:30 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9380 Archived-At: On Wed, Feb 24, 2016 at 10:11:07AM +0000, Jaydeep Patil wrote: > Hi Rich, > > Regarding the N64 relocations (changes in dynlink.h): > MIPS64 N64 relocations are slightly different than that of MIPS32 > O32. The 64-bit r_info member of the REL/RELA contains up to three > relocation types (8bits each) and two symbol table indexes (8bits > and 32bits). > > For example (extracted from libc.so): > > Offset Info Type Sym. Value Sym. Name > 0000000c4000 000000001203 R_MIPS_REL32 > Type2: R_MIPS_64 > Type3: R_MIPS_NONE > > In case of big-endian systems, R_TYPE (x & 0x7fffffff) and R_SYM (x > >> 32) macros can be used to extract type and symbol table index. > However on little-endian system, the raw r_info looks like > 0x0312000000000000 and thus the required relocation information > cannot be extracted using R_TYPE etc. macros. OK, so it really is always big endian. In that case, the following should work fine: #define R_TYPE(x) (be64toh(x)&0x7fffffff) #define R_SYM(x) (be64toh(x)>>32) Does that work for you? (be64toh is from endian.h) > > diff --git a/arch/mips64/bits/float.h b/arch/mips64/bits/float.h > > new file mode 100644 > > index 0000000..719c790 > > --- /dev/null > > +++ b/arch/mips64/bits/float.h > > @@ -0,0 +1,16 @@ > > +#define FLT_EVAL_METHOD 0 > > + > > +#define LDBL_TRUE_MIN 6.47517511943802511092443895822764655e-4966L > > +#define LDBL_MIN 3.36210314311209350626267781732175260e-4932L > > +#define LDBL_MAX 1.18973149535723176508575932662800702e+4932L > > +#define LDBL_EPSILON 1.92592994438723585305597794258492732e-34L > > + > > +#define LDBL_MANT_DIG 113 > > +#define LDBL_MIN_EXP (-16381) > > +#define LDBL_MAX_EXP 16384 > > + > > +#define LDBL_DIG 33 > > +#define LDBL_MIN_10_EXP (-4931) > > +#define LDBL_MAX_10_EXP 4932 > > + > > +#define DECIMAL_DIG 36 > > Is your mips64 port using IEEE quad? These values look like they're > matched to IEEE quad, but I couldn't find clear answers on whether > mips64 is using IEEE quad or double-double. The latter cannot be > supported, so if that's what it's using, we'd need to either find a > way to configure the compiler for quad or for 64-bit long double. > > > “Szabolcs Nagy replied as below in prior mail discussions > > bits/float.h is wrong > > if mips64 uses ieee binary128 then copy aarch64 float.h otherwise use arm float.h > > > > long double is same as double on o32 and a 128-bit IEEE quad on mips64-linux Indeed, I just tested and this seems correct. I hope potential users are okay with that -- it's going to impose a fair amount of size overhead in static linking, but maybe all mips64 systems are "big enough" that it's not a big deal. Rich