Sorry, We described details in Gentoo Bugzilla#580614. 1) When use CHOST="powerpc64le-unknown-linux-gnu" to build binutils. there is no biarch support.See current supported emulations leno@localhost ~ $ powerpc64le-unknown-linux-gnu-ld -V GNU ld (Gentoo 2.25.1 p1.1) 2.25.1 Supported emulations: elf64lppc elf32lppc elf32lppclinux elf32lppcsim But we want elf64ppc for building grub2. If we there is no elf64ppc emulation, we can't compiling grub2 and grub2-install for ppc64le platform. 2) Following are the emulations what we want leno@localhost ~ $ powerpc64le-unknown-linux-gnu-ld -V GNU ld (Gentoo 2.25.1 p1.1) 2.25.1 Supported emulations: elf64lppc elf32lppc elf32lppclinux elf32lppcsim elf32ppclinux elf32ppc elf32ppcsim elf64ppc 3) We found that --enable-targets=all make on sense to build the above emulations what we want, Workaround solution is --enable-targets="powerpc-linux-gnu" built the targets we want. But, there is no other arch-specific handling like this. Instead, binutils itself handles things by selecting a default set of supported targets based on the active host.and when i glance in there, ld/configure.tgt: powerpc*-*-elf* | powerpc*-*-eabi* | powerpc*-*-sysv* \ | powerpc*-*-linux* | powerpc*-*-netbsd* | powerpc*-*-openbsd* \ | powerpc*-*-solaris* | powerpc*-*-kaos* | powerpc*-*-vxworks*) case "${targ}" in *64*) targ_emul=elf64ppc targ_extra_emuls="elf32ppc elf32ppclinux elf32ppcsim" targ_extra_libpath="elf32ppc elf32ppclinux" td=tdir_elf32ppc case "${targ}" in powerpc*le-*) td=tdir_elf32lppc;; esac eval ${td}=`echo "${targ_alias}" | sed -e 's/64//'` eval ${td}linux=\$${td} eval ${td}sim=\$${td} ;; seems there is big-endian support for powerpc64le-unknown-linux-gnu
>>> seems there is big-endian support for powerpc64le-unknown-linux-gnu There is no big-endian support for ppc64le
(In reply to Leno Hou from comment #1) > >>> seems there is big-endian support for powerpc64le-unknown-linux-gnu > > There is no big-endian support for ppc64le what do you mean? ppc64le is little endian. ppc64 is big-endian.
Soooorry for the incorrect description, Again, we can't get elf64ppc emulation on powerpc64 little-endian( abbrev. ppc64le) when building binutils. If there is no elf64ppc emulations, we can't build grub2 for ppc64le.
(In reply to Leno Hou from comment #3) > Soooorry for the incorrect description, > > Again, > > we can't get elf64ppc emulation on powerpc64 little-endian( abbrev. ppc64le) > when building binutils. If there is no elf64ppc emulations, we can't build > grub2 for ppc64le. Thanks that clarifies matters.
Created attachment 9219 [details] Proposed patch Hi Leno, Please could you try out this patch and see if it works for you ? Cheers Nick
Thanks Nick, This is works fine with me, Great.
The master branch has been updated by Nick Clifton <nickc@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=731bb67af7ba357164095a035749e3aaa9ac1f4f commit 731bb67af7ba357164095a035749e3aaa9ac1f4f Author: Nick Clifton <nickc@redhat.com> Date: Mon Apr 25 17:25:27 2016 +0100 Allow powerpc64le-linux-gnu toolchain to support big endian targets as well. PR target/19985 * configure.tgt: Include big endian PPC64 emulations with little endian PPC64 targets.
Patch applied.
Since 32-bit userspace isn't supported for powerpc64le it doesn't make much sense to enable 32-bit support in binutils by default. grub2 is special. It needs a toolchain that supports powerpc big-endian, which means you actually require a cross-toolchain. While it is possible to build binutils and gcc to support both native ppc64le and big-endian ppc64/ppc32 I don't believe we should do that by default.
(In reply to Alan Modra from comment #9) counter point: bfd already does it for powerpc linux targets (and more): ppc -> enable BE & LE, 32 & 64, default to BE/32 ppcle -> enable BE & LE, 32 & 64, default to LE/32 ppc64 -> enable BE & LE, 32 & 64, default to BE/64 ppc64le -> enable BE & LE, 32 & 64, default to LE/64 the linker should be consistent, and including these targets by default adds very little overhead. it already has been at least to get biarch support. you're right that gcc doesn't do this by default, but it's trivial to pass --enable-targets=all, and also adds very little overhead. plus, i expect most people do this already in order to just get biarch support (32bit+64bit) which is needed to build a 64bit kernel from a 32bit userland (and a 32bit kernel from a 64bit userland which still makes sense in the VM case). this does not require a full toolchain as it only affects gcc's codegen steps. which is the only thing grub cares about since it's producing bare metal code here. so what's the problem with having the linker be consistent with bfd and including the full 32/64 be/le matrix by default ? afaict, at least bfd has behaved this way for over a decade and no one has noticed/cared/complained.
It used to be that you were much better off *not* having the big-endian linker targets available by default, so that makefiles that wrongly passed -melf64ppc caused powerpc64le-linux-ld to give an obvious error relating to its command line rather than something more obscure. I suppose most of those package problems have been fixed nowadays, so perhaps making the big-endian targets available isn't such a bad thing.
(In reply to Alan Modra from comment #11) i can't speak too much to ppc-specific codebases, but i think the wider ecosystem has gotten sane now (especially with libtool handling a lot now). Leno has been going through much of Gentoo to track down the missing pieces, so hopefully we should be able to shake those cases out too.
Hi Alan, >> makefiles that wrongly passed -melf64ppc caused powerpc64le-linux-ld to give an >>obvious error relating to its command line rather than something more obscure. aclocal -> automake -> libtoolize -> autoconf -> configure -> Makefile During this work flow, we've patched libtool.m4 as below which is make sure generate correct Makefile and passed correct $LD="ld -m elf64lppc' to powerpc64le-linux-ld >> I suppose most of those package problems have been fixed nowadays, so perhaps making the big-endian targets available isn't such a bad thing. So I must make sure that all packages with -melf64ppc was updated by elibtoolize or eautoreconf. Then we'll enable big-endian targets on gentoo ppc64le.
The master branch has been updated by Alan Modra <amodra@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=13b8c3356bc76abc3624ea9348cc8e834594dfe0 commit 13b8c3356bc76abc3624ea9348cc8e834594dfe0 Author: Alan Modra <amodra@gmail.com> Date: Wed Apr 27 16:51:15 2016 +0930 Fix powerpc64 ld testsuite fail PR target/19985 * configure.tgt: Don't use var+=.
Hi Alan Modra, When used your patch, below is not we expected. localhost files # ld -V GNU ld (Gentoo 2.25.1 p1.1) 2.25.1 Supported emulations: elf64lppc elf32lppc elf32lppclinux elf32lppcsim elf64ppc What we expect is localhost files # ld -V GNU ld (Gentoo 2.25.1 p1.1) 2.25.1 Supported emulations: elf64lppc elf32ppc elf32ppclinux elf32ppcsim elf32lppc elf32lppclinux elf32lppcsim elf64ppc Could you help to me what happened ? Thanks. Nick Clifton's patch works well with me.
I am far from omniscient, so no, I can't tell you what you or Gentoo did. The patch that I committed to binutils master on top of Nick's patch merely fixed use of += in shell scripts, a feature not supported by all shells. I see this for --target=powerpc64le-linux on master GNU ld (GNU Binutils) 2.26.51.20160514 Supported emulations: elf64lppc elf32ppc elf32ppclinux elf32ppcsim elf32lppc elf32lppclinux elf32lppcsim elf64ppc