
Date: Wed, 24 Feb 2016 12:53:12 0500 From: "dalias@...c.org" <dalias@...c.org> To: Jaydeep Patil <Jaydeep.Patil@...tec.com> Cc: "musl@...ts.openwall.com" <musl@...ts.openwall.com>, Mahesh Bodapati <Mahesh.Bodapati@...tec.com> Subject: Re: mips n64 porting review 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 64bit 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 bigendian systems, R_TYPE (x & 0x7fffffff) and R_SYM (x > >> 32) macros can be used to extract type and symbol table index. > However on littleendian 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.47517511943802511092443895822764655e4966L > > +#define LDBL_MIN 3.36210314311209350626267781732175260e4932L > > +#define LDBL_MAX 1.18973149535723176508575932662800702e+4932L > > +#define LDBL_EPSILON 1.92592994438723585305597794258492732e34L > > + > > +#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 doubledouble. 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 64bit 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 128bit IEEE quad on mips64linux 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
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.