This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v2] [Gold,MIPS] Detect 64-bit MIPS targets


On 2016-08-22 16:53, Maciej W. Rozycki wrote:
> Hi Aurelien,
> 
> > > gold/Changelog:
> > > 	* configure.tgt: Add mips*64*el*-*-*|mips*64*le*-*-* and mips*64*-*-*.
> 
>  Hmm, `mips*64*le*-*-*' is not a standard machine triplet, e.g.:
> 
> $ ./config.sub mips64le-linux
> Invalid configuration `mips64le-linux': machine `mips64le' not recognized
> $ 
> 
> so please drop it.  The little endianness for MIPS machines has been 
> selected solely with the `el' suffix, e.g.:
> 
> $ ./config.sub mips64el-linux
> mips64el-unknown-linux-gnu
> $ 

I have done it that way as mipsel was define that way. Now it seems to
be wrong there too as mipsle-linux-gnu is not recognized by config.sub
either. I'll fix that in the next version.

> > > diff --git a/gold/configure.tgt b/gold/configure.tgt
> > > index f1fd132..e119df0 100644
> > > --- a/gold/configure.tgt
> > > +++ b/gold/configure.tgt
> > > @@ -153,6 +153,13 @@ aarch64*-*)
> > >   targ_big_endian=false
> > >   targ_extra_big_endian=true
> > >   ;;
> > > +mips*64*el*-*-*|mips*64*le*-*-*)
> > > + targ_obj=mips
> > > + targ_machine=EM_MIPS_RS3_LE
> > > + targ_size=64
> > > + targ_big_endian=false
> > > + targ_extra_big_endian=true
> > > + ;;
> > >  mips*el*-*-*|mips*le*-*-*)
> > >   targ_obj=mips
> > >   targ_machine=EM_MIPS_RS3_LE
> > > @@ -160,6 +167,13 @@ mips*el*-*-*|mips*le*-*-*)
> > >   targ_big_endian=false
> > >   targ_extra_big_endian=true
> > >   ;;
> > > +mips*64*-*-*)
> > > + targ_obj=mips
> > > + targ_machine=EM_MIPS
> > > + targ_size=64
> > > + targ_big_endian=true
> > > + targ_extra_big_endian=false
> > > + ;;
> > >  mips*-*-*)
> > >   targ_obj=mips
> > >   targ_machine=EM_MIPS
> 
>  The change LGTM otherwise, although I cannot approve it as I have no 
> authority for GOLD.

Ok, sorry, I though you can commit any MIPS stuff. I'll try to find
someone else then.

>  While at it it looks strange if not wrong to me that EM_MIPS_RS3_LE is 
> used by GOLD for the little-endian target given that no other tool uses 
> that ELF machine type -- it's been reserved around the time the original 
> SVR4 MIPS psABI has been created, but AFAIK never actually used as EI_DATA 
> already provides endianness information, so an extra machine type is 
> redundant.
> 
>  There's a further confusion around this machine type as the original SVR4 
> ELF gABI defines:
> 
> EM_MIPS          8  MIPS RS3000 Big-Endian
> EM_MIPS_RS4_BE  10  MIPS RS4000 Big-Endian
> 
> (RS3000/RS4000, sic!) the original SVR4 MIPS psABI has this:
> 
> "Processor identification resides in the ELF header e_machine member and 
> must have the value 8, defined as the name EM_MIPS."
> 
> and we have:
> 
> #define EM_MIPS		  8	/* MIPS R3000 (officially, big-endian only) */
> #define EM_MIPS_RS3_LE	 10	/* MIPS R3000 little-endian (Oct 4 1999 Draft) Deprecated */
> 
>  Do binaries with EM_MIPS_RS3_LE marking actually work at all, e.g. does 
> the Linux kernel and `ld.so', or firmware loaders (CFE, etc.) accept them?

I haven't tried that. Anyway I have just looked at the binary produced
by ld.gold and they use EM_MIPS even if targ_machine says
EM_MIPS_RS3_LE.

It looks like I have to investigate more, also because the change to
gold/configure.tgt was not necessary with 2.16.1. I have still haven't
understood why.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]