Re: ppc64 binutils

Re: ppc64 binutils

[Geoff Keating]

> Date: Mon, 6 Aug 2001 11:54:13 +0930
> From: Alan Modra <amodra@bigpond.net.au>
> Content-Disposition: inline
> User-Agent: Mutt/1.3.17i
> 
> Hi Geoff,
>   Have you had a chance to look at
> http://sources.redhat.com/ml/binutils/2001-07/msg00612.html ?
> Any objections to me checking it in?

Here are some comments:

--- binutils-ppc64.orig/bfd/cpu-powerpc.c       Fri May  4 22:22:20 2001
+++ binutils-ppc64/bfd/cpu-powerpc.c    Wed Aug  1 12:56:15 2001
@@ -128,7 +128,7 @@ static const bfd_arch_info_type arch_inf
     "powerpc",
     "powerpc:620",
     3,
-    false, /* not the default */
+    BFD_ARCH_SIZE == 64, /* default for 64 bit target */
     powerpc_compatible,
     bfd_default_scan,
     &arch_info_struct[6]
@@ -229,7 +229,7 @@ const bfd_arch_info_type bfd_powerpc_arc
     "powerpc",
     "powerpc:common",
     3,
-    true, /* the default */
+    BFD_ARCH_SIZE != 64, /* default for 32 bit target */
     powerpc_compatible,
     bfd_default_scan,
     &arch_info_struct[0]

This can't possibly be right.  BFD_ARCH_SIZE is a property of the
host.

--- binutils-ppc64.orig/bfd/elflink.c   Fri Jul  6 11:42:20 2001
+++ binutils-ppc64/bfd/elflink.c        Wed Aug  1 12:56:15 2001

You'll need to get Nick to review this part.  It seems like it would
affect all targets.  Have you tested it on other targets?

+ENUMX
+  BFD_RELOC_PPC64_PLTGOT16   

You might consider sharing some other _PLTGOT16 reloc, to help reduce
duplicated code.

--- binutils-ppc64.orig/binutils/testsuite/binutils-all/readelf.s-64    Fri Jul  6 11:42:20 2001
+++ binutils-ppc64/binutils/testsuite/binutils-all/readelf.s-64 Wed
Aug  1 12:56:15 2001

Are you sure this change doesn't break the testcase on some
other target?  It seems to reduce the inputs allowed.

+++ binutils-ppc64/gas/ChangeLog.swox   Wed Aug  1 13:40:49 2001

These should be folded into the toplevel ChangeLog, indented inside
the entry where the file is added.

+++ binutils-ppc64/gas/config/obj-elf.c Wed Aug  1 12:56:15 2001

This is another generic change.  Could you please submit changes to
the generic part separately from the new port?  Also submit changes to
the ppc config (that change the way the existing ppc stuff works)
separately from the changes that introduce the new port.

+/* Read AIX assembly syntax?  User selects it with command line option
+   `-Saix'.  Default is to allow just proper ELF syntax.  */

If this is not needed (and never will be) by released FSF compilers,
there's no need to put it in the released FSF binutils.  Anyone who is
using a patched compiler can presumably find the patched binutils.

+++ binutils-ppc64/gas/testsuite/ChangeLog.swox Wed Aug  1 13:41:29
2001

It's good to see so many testcases!

+++ binutils-ppc64/ld/emulparams/crislinux.sh   Wed Aug  1 12:56:16 2001

That certainly requires an explanation.

+++ binutils-ppc64/ld/genscripts.sh     Wed Aug  1 12:56:16 2001

Submit separately, please.

+       # PowerPc64 srec linker can't handle .toc relocations.

Um, why?

+++ binutils-ppc64/opcodes/ppc-opc.c    Wed Aug  1 12:56:16 2001

I think this change really needs to come in two parts, one that does
the boring change of making the structure larger, and one that adds
new instructions.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: ppc64 binutils

[Alan Modra]

On Sun, Aug 05, 2001 at 08:19:41PM -0700, Geoff Keating wrote:
> 
> This can't possibly be right.  BFD_ARCH_SIZE is a property of the
> host.

Hmm, yes, you get BFD_ARCH_SIZE == 64 if either the host or target is
64 bit.  That would make building the 32 bit target from a 64 bit host
wrong.  I'll see about a different solution.

> --- binutils-ppc64.orig/binutils/testsuite/binutils-all/readelf.s-64    Fri Jul  6 11:42:20 2001
> +++ binutils-ppc64/binutils/testsuite/binutils-all/readelf.s-64 Wed
> Aug  1 12:56:15 2001
> 
> Are you sure this change doesn't break the testcase on some
> other target?  It seems to reduce the inputs allowed.

No, I'm not sure but did build a few 64 bit targets.  Reducing the
allowed inputs was intentional, and I suppose I should have said so
in the ChangeLog.  I figure that eg. [45][c4] was meant to match 4c
or 54, as they were the values I found.

> +++ binutils-ppc64/gas/ChangeLog.swox   Wed Aug  1 13:40:49 2001
> 
> These should be folded into the toplevel ChangeLog, indented inside
> the entry where the file is added.

Sure.  Wasn't that what I said?

> +++ binutils-ppc64/gas/config/obj-elf.c Wed Aug  1 12:56:15 2001
> 
> This is another generic change.  Could you please submit changes to
> the generic part separately from the new port?  Also submit changes to
> the ppc config (that change the way the existing ppc stuff works)
> separately from the changes that introduce the new port.

OK.

> +/* Read AIX assembly syntax?  User selects it with command line option
> +   `-Saix'.  Default is to allow just proper ELF syntax.  */
> 
> If this is not needed (and never will be) by released FSF compilers,
> there's no need to put it in the released FSF binutils.  Anyone who is
> using a patched compiler can presumably find the patched binutils.
> 
> +++ binutils-ppc64/gas/testsuite/ChangeLog.swox Wed Aug  1 13:41:29
> 2001
> 
> It's good to see so many testcases!

Some of which will need to be removed if -Saix goes.

> +++ binutils-ppc64/ld/emulparams/crislinux.sh   Wed Aug  1 12:56:16 2001
> 
> That certainly requires an explanation.
> 
> +++ binutils-ppc64/ld/genscripts.sh     Wed Aug  1 12:56:16 2001
> 
> Submit separately, please.

OK.  I intended to make the commit in a number of pieces, and this is
one of the obvious bits to do separately.

> +       # PowerPc64 srec linker can't handle .toc relocations.
> 
> Um, why?

Lots of "relocation truncated to fit: R_PPC64_TOC16_DS toc", because the
generic srec linker doesn't do any fancy relocations.

> +++ binutils-ppc64/opcodes/ppc-opc.c    Wed Aug  1 12:56:16 2001
> 
> I think this change really needs to come in two parts, one that does
> the boring change of making the structure larger, and one that adds
> new instructions.

I was lazy, I admit it.  Thanks for looking it over anyway.  I'll commit
a number of changes that provide extra infrastructure, and we'll go from
there.

Alan