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 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
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.