* [PATCH v2] [Gold,MIPS] Detect 64-bit MIPS targets
@ 2016-08-09 19:24 Aurelien Jarno
2016-08-21 15:56 ` Aurelien Jarno
0 siblings, 1 reply; 7+ messages in thread
From: Aurelien Jarno @ 2016-08-09 19:24 UTC (permalink / raw)
To: binutils; +Cc: Aurelien Jarno
When building gold targetting a 64-bit target like for example
mips64el-linux-gnu or mipsisa64r6-linux-gnu, the configure script does
not set HAVE_TARGET_64_LITTLE or HAVE_TARGET_64_BIG. This causes the
link of gold to fail:
mips.o: In function `(anonymous namespace)::Target_mips<64, true>::set_gp(gold::Layout*, gold::Symbol_table*) [clone .isra.1854]':
/home/aurel32/git/binutils-gdb/gold/mips.cc:8377: undefined reference to `gold::Sized_symbol<64>::init_output_data(char const*, char const*, gold::Output_data*, unsigned long, unsigned long, elfcpp::STT, elfcpp::STB, elfcpp::STV, unsigned char, bool, bool)'
mips.o: In function `gold::Merged_symbol_value<64>::value(gold::Relobj const*, unsigned int, unsigned long) const':
/home/aurel32/git/binutils-gdb/gold/object.h:1649: undefined reference to `gold::Merged_symbol_value<64>::value_from_output_section(gold::Relobj const*, unsigned int, unsigned long) const'
/home/aurel32/git/binutils-gdb/gold/object.h:1649: undefined reference to `gold::Merged_symbol_value<64>::value_from_output_section(gold::Relobj const*, unsigned int, unsigned long) const'
...
Fix that by adding mips*64*el and mips*64* entries in gold/configure.tgt
gold/Changelog:
* configure.tgt: Add mips*64*el*-*-*|mips*64*le*-*-* and mips*64*-*-*.
---
gold/ChangeLog | 4 ++++
gold/configure.tgt | 14 ++++++++++++++
2 files changed, 18 insertions(+)
I have been pointed that it doesn't fix the mips64r6 targets. This new
patch takes them into account.
diff --git a/gold/ChangeLog b/gold/ChangeLog
index 239df36..45b10f5 100644
--- a/gold/ChangeLog
+++ b/gold/ChangeLog
@@ -1,3 +1,7 @@
+2016-08-09 Aurelien Jarno <aurelien@aurel32.net>
+
+ * configure.tgt: Add mips*64*el*-*-*|mips*64*le*-*-* and mips*64*-*-*.
+
2016-06-29 Cary Coutant <ccoutant@gmail.com>
gold/
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
--
2.8.1
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] [Gold,MIPS] Detect 64-bit MIPS targets
2016-08-09 19:24 [PATCH v2] [Gold,MIPS] Detect 64-bit MIPS targets Aurelien Jarno
@ 2016-08-21 15:56 ` Aurelien Jarno
2016-08-22 15:53 ` Maciej W. Rozycki
0 siblings, 1 reply; 7+ messages in thread
From: Aurelien Jarno @ 2016-08-21 15:56 UTC (permalink / raw)
To: binutils; +Cc: Maciej W. Rozycki
Ping.
On 2016-08-09 21:24, Aurelien Jarno wrote:
> When building gold targetting a 64-bit target like for example
> mips64el-linux-gnu or mipsisa64r6-linux-gnu, the configure script does
> not set HAVE_TARGET_64_LITTLE or HAVE_TARGET_64_BIG. This causes the
> link of gold to fail:
>
> mips.o: In function `(anonymous namespace)::Target_mips<64, true>::set_gp(gold::Layout*, gold::Symbol_table*) [clone .isra.1854]':
> /home/aurel32/git/binutils-gdb/gold/mips.cc:8377: undefined reference to `gold::Sized_symbol<64>::init_output_data(char const*, char const*, gold::Output_data*, unsigned long, unsigned long, elfcpp::STT, elfcpp::STB, elfcpp::STV, unsigned char, bool, bool)'
> mips.o: In function `gold::Merged_symbol_value<64>::value(gold::Relobj const*, unsigned int, unsigned long) const':
> /home/aurel32/git/binutils-gdb/gold/object.h:1649: undefined reference to `gold::Merged_symbol_value<64>::value_from_output_section(gold::Relobj const*, unsigned int, unsigned long) const'
> /home/aurel32/git/binutils-gdb/gold/object.h:1649: undefined reference to `gold::Merged_symbol_value<64>::value_from_output_section(gold::Relobj const*, unsigned int, unsigned long) const'
> ...
>
> Fix that by adding mips*64*el and mips*64* entries in gold/configure.tgt
>
> gold/Changelog:
> * configure.tgt: Add mips*64*el*-*-*|mips*64*le*-*-* and mips*64*-*-*.
> ---
> gold/ChangeLog | 4 ++++
> gold/configure.tgt | 14 ++++++++++++++
> 2 files changed, 18 insertions(+)
>
> I have been pointed that it doesn't fix the mips64r6 targets. This new
> patch takes them into account.
>
> diff --git a/gold/ChangeLog b/gold/ChangeLog
> index 239df36..45b10f5 100644
> --- a/gold/ChangeLog
> +++ b/gold/ChangeLog
> @@ -1,3 +1,7 @@
> +2016-08-09 Aurelien Jarno <aurelien@aurel32.net>
> +
> + * configure.tgt: Add mips*64*el*-*-*|mips*64*le*-*-* and mips*64*-*-*.
> +
> 2016-06-29 Cary Coutant <ccoutant@gmail.com>
>
> gold/
> 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
> --
> 2.8.1
>
>
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] [Gold,MIPS] Detect 64-bit MIPS targets
2016-08-21 15:56 ` Aurelien Jarno
@ 2016-08-22 15:53 ` Maciej W. Rozycki
2016-08-22 20:33 ` Aurelien Jarno
0 siblings, 1 reply; 7+ messages in thread
From: Maciej W. Rozycki @ 2016-08-22 15:53 UTC (permalink / raw)
To: Aurelien Jarno; +Cc: binutils
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
$
> > 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.
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?
Maciej
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] [Gold,MIPS] Detect 64-bit MIPS targets
2016-08-22 15:53 ` Maciej W. Rozycki
@ 2016-08-22 20:33 ` Aurelien Jarno
2016-08-23 22:21 ` Aurelien Jarno
0 siblings, 1 reply; 7+ messages in thread
From: Aurelien Jarno @ 2016-08-22 20:33 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: binutils
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] [Gold,MIPS] Detect 64-bit MIPS targets
2016-08-22 20:33 ` Aurelien Jarno
@ 2016-08-23 22:21 ` Aurelien Jarno
2016-09-12 18:53 ` Cary Coutant
0 siblings, 1 reply; 7+ messages in thread
From: Aurelien Jarno @ 2016-08-23 22:21 UTC (permalink / raw)
To: Maciej W. Rozycki, binutils
On 2016-08-22 22:33, Aurelien Jarno wrote:
> On 2016-08-22 16:53, Maciej W. Rozycki wrote:
> 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 seems that the binary produced by ld.gold is using the value from
the input objects, that's why it ends up with EM_MIPS. Still that is
something to be fixed in configure.tgt.
> 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.
With 2.16.1, --enable-gold is just ignored when building on mips, so the
build issue doesn't happen.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] [Gold,MIPS] Detect 64-bit MIPS targets
2016-08-23 22:21 ` Aurelien Jarno
@ 2016-09-12 18:53 ` Cary Coutant
2016-09-27 22:25 ` Aurelien Jarno
0 siblings, 1 reply; 7+ messages in thread
From: Cary Coutant @ 2016-09-12 18:53 UTC (permalink / raw)
To: Maciej W. Rozycki, Binutils
Is there anything more to be done with this proposed patch? I'll be
happy to commit a fix, but from this discussion, I'm not really sure
what the correct fix is.
-cary
On Tue, Aug 23, 2016 at 3:20 PM, Aurelien Jarno <aurelien@aurel32.net> wrote:
> On 2016-08-22 22:33, Aurelien Jarno wrote:
>> On 2016-08-22 16:53, Maciej W. Rozycki wrote:
>> 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 seems that the binary produced by ld.gold is using the value from
> the input objects, that's why it ends up with EM_MIPS. Still that is
> something to be fixed in configure.tgt.
>
>> 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.
>
> With 2.16.1, --enable-gold is just ignored when building on mips, so the
> build issue doesn't happen.
>
> Aurelien
>
> --
> Aurelien Jarno GPG: 4096R/1DDD8C9B
> aurelien@aurel32.net http://www.aurel32.net
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] [Gold,MIPS] Detect 64-bit MIPS targets
2016-09-12 18:53 ` Cary Coutant
@ 2016-09-27 22:25 ` Aurelien Jarno
0 siblings, 0 replies; 7+ messages in thread
From: Aurelien Jarno @ 2016-09-27 22:25 UTC (permalink / raw)
To: Cary Coutant; +Cc: Maciej W. Rozycki, Binutils
On 2016-09-12 11:53, Cary Coutant wrote:
> Is there anything more to be done with this proposed patch? I'll be
> happy to commit a fix, but from this discussion, I'm not really sure
> what the correct fix is.
Sorry, I have been busy. I'll send a new version of the patchset soon.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-09-27 22:25 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-09 19:24 [PATCH v2] [Gold,MIPS] Detect 64-bit MIPS targets Aurelien Jarno
2016-08-21 15:56 ` Aurelien Jarno
2016-08-22 15:53 ` Maciej W. Rozycki
2016-08-22 20:33 ` Aurelien Jarno
2016-08-23 22:21 ` Aurelien Jarno
2016-09-12 18:53 ` Cary Coutant
2016-09-27 22:25 ` Aurelien Jarno
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 read-only IMAP folder(s) and NNTP newsgroup(s).