Re: mips n64 porting review

["dalias@libc.org" <dalias@libc.org>]

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