[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160224175312.GS9349@brightrain.aerifal.cx>
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.
