From: Jaydeep Patil <Jaydeep.Patil@imgtec.com>
To: "dalias@libc.org" <dalias@libc.org>
Cc: "musl@lists.openwall.com" <musl@lists.openwall.com>,
Mahesh Bodapati <Mahesh.Bodapati@imgtec.com>
Subject: RE: mips n64 porting review
Date: Thu, 25 Feb 2016 08:21:09 +0000 [thread overview]
Message-ID: <BD7773622145634B952E5B54ACA8E349AA2441E4@PUMAIL01.pu.imgtec.org> (raw)
In-Reply-To: <20160224175312.GS9349@brightrain.aerifal.cx>
> -----Original Message-----
> From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of dalias@libc.org
> Sent: 24 February 2016 PM 11:23
> To: Jaydeep Patil
> Cc: musl@lists.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
next prev parent reply other threads:[~2016-02-25 8:21 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-22 10:06 Mahesh Bodapati
2016-02-22 14:16 ` Bobby Bingham
2016-02-23 3:32 ` Rich Felker
[not found] ` <CAKd0kD+qQhvhiuaQ483ds2KyGD5qFjqJg4pOT6GyqCaoR9_auA@mail.gmail.com>
[not found] ` <DE16056458B9894F9D46202EC1BBB28B3BE16033@PUMAIL01.pu.imgtec.org>
2016-02-24 10:11 ` Jaydeep Patil
2016-02-24 17:53 ` dalias
2016-02-25 8:21 ` Jaydeep Patil [this message]
[not found] ` <DE16056458B9894F9D46202EC1BBB28B3BE162B3@PUMAIL01.pu.imgtec.org>
2016-02-25 12:05 ` Jaydeep Patil
2016-02-25 18:01 ` dalias
2016-02-25 18:22 ` dalias
2016-02-26 3:58 ` Jaydeep Patil
2016-02-25 18:23 ` Szabolcs Nagy
2016-02-25 18:29 ` Szabolcs Nagy
2016-02-25 18:31 ` Rich Felker
[not found] <DE16056458B9894F9D46202EC1BBB28B3BDC3210@PUMAIL01.pu.imgtec.org>
2016-02-03 23:36 ` Rich Felker
2016-02-04 0:45 ` Szabolcs Nagy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BD7773622145634B952E5B54ACA8E349AA2441E4@PUMAIL01.pu.imgtec.org \
--to=jaydeep.patil@imgtec.com \
--cc=Mahesh.Bodapati@imgtec.com \
--cc=dalias@libc.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).