[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <BD7773622145634B952E5B54ACA8E349AA2441E4@PUMAIL01.pu.imgtec.org>
Date: Thu, 25 Feb 2016 08:21:09 +0000
From: Jaydeep Patil <Jaydeep.Patil@...tec.com>
To: "dalias@...c.org" <dalias@...c.org>
CC: "musl@...ts.openwall.com" <musl@...ts.openwall.com>, Mahesh Bodapati
<Mahesh.Bodapati@...tec.com>
Subject: RE: mips n64 porting review
> -----Original Message-----
> From: Rich Felker [mailto:dalias@...ifal.cx] On Behalf Of dalias@...c.org
> Sent: 24 February 2016 PM 11:23
> To: Jaydeep Patil
> Cc: musl@...ts.openwall.com; Mahesh Bodapati
> Subject: Re: [musl] 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)
Following macros work fine for both big and little endian systems:
#define R_TYPE(x) (be64toh(x)&0x7fffffff)
#define R_SYM(x) (be32toh(be64toh(x)>>32))
#define R_INFO(s,t) (htobe64((uint64_t)htobe32(s)<<32 | (uint64_t)t))
> 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.
Thanks
> Rich
Regards,
Jaydeep
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.
