[PATCH] MIPS gas/ld test suite portability fixes

[PATCH] MIPS gas/ld test suite portability fixes

[Maciej W. Rozycki]

Hello,

 It's generally unsafe to assume the default MIPS arch type will work for 
NewABI tests (although it may happen to be the case with the targets that 
currently enable them).  For example we get several failures with our SDE 
toolchain if we configure it for mipsisa32-*.  I think it shouldn't hurt 
to specify a compatible arch explicitly.

 We get failures due to a different alignment of sections, too.  Finally 
one of the ld cases omits emulation specification, which may also lead to 
a failure.

 Here's a fix that addresses these issues.  No regressions for 
mips64-linux-gnu.

gas/testsuite/:
2005-02-22  Maciej W. Rozycki  <macro@mips.com>

	* mips/elf-rel-got-n32.d: Pass -march=mips3 to gas to select a
	64-bit architecture.
	* mips/elf-rel-got-n64.d: Likewise.
	* mips/elf-rel-xgot-n32.d: Likewise.
	* mips/elf-rel-xgot-n64.d: Likewise.
	* mips/elf-rel18.d: Likewise.
	* gas/mips/jal-newabi.d: Likewise.
	* gas/mips/ldstla-n32-shared.d: Likewise.
	* gas/mips/ldstla-n32.d: Likewise.
	* gas/mips/ldstla-n64-shared.d: Likewise.
	* gas/mips/ldstla-n64.d: Likewise.
	* gas/mips/macro-warn-1-n32.d: Likewise.
	* gas/mips/macro-warn-2-n32.d: Likewise.
	* gas/mips/n32-consec.d: Likewise.
	* mips/elf-rel-got-n32.s: Align to 16 bytes for multi-target
	support.
	* mips/elf-rel-got-n64.s: Likewise.
	* mips/elf-rel23.s: Likewise.
	* gas/mips/n32-consec.s: Likewise.

ld/testsuite/:
2005-02-22  Maciej W. Rozycki  <macro@mips.com>

	* ld-mips-elf/elf-rel-got-n32.d: Pass -march=mips3 to gas to
	select a 64-bit architecture.
	* ld-mips-elf/elf-rel-got-n64.d: Likewise.
	* ld-mips-elf/elf-rel-xgot-n32.d: Likewise.
	* ld-mips-elf/elf-rel-xgot-n64.d: Likewise.
	* ld-mips-elf/relax-jalr-n32-shared.d: Likewise.
	* ld-mips-elf/relax-jalr-n32.d: Likewise.
	* ld-mips-elf/relax-jalr-n64-shared.d: Likewise.
	* ld-mips-elf/relax-jalr-n64.d: Likewise.
	* ld-mips-elf/reloc-1-n32.d: Likewise.
	* ld-mips-elf/reloc-1-n64.d: Likewise.
	* ld-mips-elf/jalbal.d: Pass -melf32btsmipn32 to ld to select an
	n32 emulation.

 OK to apply?

  Maciej

binutils-2.15.94-20050222-mips-newabi-tests.patch
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/elf-rel-got-n32.d binutils-2.15.94-20050222/gas/testsuite/gas/mips/elf-rel-got-n32.d
--- binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/elf-rel-got-n32.d	2004-02-02 12:48:21.000000000 +0000
+++ binutils-2.15.94-20050222/gas/testsuite/gas/mips/elf-rel-got-n32.d	2005-02-22 15:53:40.000000000 +0000
@@ -1,6 +1,6 @@
 #objdump: -dr --prefix-addresses --show-raw-insn
 #name: MIPS ELF got reloc n32
-#as: -n32 -KPIC
+#as: -march=mips3 -n32 -KPIC
 
 .*: +file format elf32-n.*mips.*
 
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/elf-rel-got-n32.s binutils-2.15.94-20050222/gas/testsuite/gas/mips/elf-rel-got-n32.s
--- binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/elf-rel-got-n32.s	2003-04-11 01:56:51.000000000 +0000
+++ binutils-2.15.94-20050222/gas/testsuite/gas/mips/elf-rel-got-n32.s	2005-02-11 19:54:23.000000000 +0000
@@ -151,6 +151,9 @@ fn2:
 	.globl  __start
 __start:
 	
+# align section end to 16-byte boundary for easier testing on multiple targets
+	.p2align 4
+
 	.data
 	.align	2
 sp2:
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/elf-rel-got-n64.d binutils-2.15.94-20050222/gas/testsuite/gas/mips/elf-rel-got-n64.d
--- binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/elf-rel-got-n64.d	2004-02-02 12:48:21.000000000 +0000
+++ binutils-2.15.94-20050222/gas/testsuite/gas/mips/elf-rel-got-n64.d	2005-02-22 15:53:40.000000000 +0000
@@ -1,6 +1,6 @@
 #objdump: -dr --prefix-addresses --show-raw-insn
 #name: MIPS ELF got reloc n64
-#as: -64 -KPIC
+#as: -march=mips3 -64 -KPIC
 
 .*: +file format elf64-.*mips.*
 
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/elf-rel-got-n64.s binutils-2.15.94-20050222/gas/testsuite/gas/mips/elf-rel-got-n64.s
--- binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/elf-rel-got-n64.s	2003-04-11 01:56:51.000000000 +0000
+++ binutils-2.15.94-20050222/gas/testsuite/gas/mips/elf-rel-got-n64.s	2005-02-11 19:56:16.000000000 +0000
@@ -152,6 +152,9 @@ fn2:
 	.globl  __start
 __start:
 	
+# align section end to 16-byte boundary for easier testing on multiple targets
+	.p2align 4
+
 	.data
 	.align	3
 sp2:
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/elf-rel-xgot-n32.d binutils-2.15.94-20050222/gas/testsuite/gas/mips/elf-rel-xgot-n32.d
--- binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/elf-rel-xgot-n32.d	2004-02-02 12:48:21.000000000 +0000
+++ binutils-2.15.94-20050222/gas/testsuite/gas/mips/elf-rel-xgot-n32.d	2005-02-22 15:53:40.000000000 +0000
@@ -1,6 +1,6 @@
 #objdump: -dr --prefix-addresses --show-raw-insn
 #name: MIPS ELF xgot reloc n32
-#as: -n32 -KPIC -xgot
+#as: -march=mips3 -n32 -KPIC -xgot
 #source: elf-rel-got-n32.s
 
 .*: +file format elf32-n.*mips.*
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/elf-rel-xgot-n64.d binutils-2.15.94-20050222/gas/testsuite/gas/mips/elf-rel-xgot-n64.d
--- binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/elf-rel-xgot-n64.d	2004-02-02 12:48:21.000000000 +0000
+++ binutils-2.15.94-20050222/gas/testsuite/gas/mips/elf-rel-xgot-n64.d	2005-02-22 15:53:40.000000000 +0000
@@ -1,6 +1,6 @@
 #objdump: -dr --prefix-addresses --show-raw-insn
 #name: MIPS ELF xgot reloc n64
-#as: -64 -KPIC -xgot
+#as: -march=mips3 -64 -KPIC -xgot
 #source: elf-rel-got-n64.s
 
 .*: +file format elf64-.*mips.*
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/elf-rel18.d binutils-2.15.94-20050222/gas/testsuite/gas/mips/elf-rel18.d
--- binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/elf-rel18.d	2004-01-12 09:30:49.000000000 +0000
+++ binutils-2.15.94-20050222/gas/testsuite/gas/mips/elf-rel18.d	2005-02-22 15:53:40.000000000 +0000
@@ -1,5 +1,5 @@
 #readelf: --relocs
-#as: -mabi=n32 -KPIC
+#as: -march=mips3 -mabi=n32 -KPIC
 
 Relocation section '\.rela\.text' at offset .* contains 4 entries:
  Offset     Info    Type            Sym.Value  Sym. Name \+ Addend
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/elf-rel23.s binutils-2.15.94-20050222/gas/testsuite/gas/mips/elf-rel23.s
--- binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/elf-rel23.s	2004-10-07 22:29:19.000000000 +0000
+++ binutils-2.15.94-20050222/gas/testsuite/gas/mips/elf-rel23.s	2005-02-22 15:53:40.000000000 +0000
@@ -4,3 +4,6 @@
 foo:
 	.cpsetup $4,$5,foo
 	.end	foo
+
+# align section end to 16-byte boundary for easier testing on multiple targets
+	.p2align 4
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/jal-newabi.d binutils-2.15.94-20050222/gas/testsuite/gas/mips/jal-newabi.d
--- binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/jal-newabi.d	2003-06-21 21:38:03.000000000 +0000
+++ binutils-2.15.94-20050222/gas/testsuite/gas/mips/jal-newabi.d	2005-02-11 18:58:55.000000000 +0000
@@ -1,6 +1,6 @@
 #objdump: -dr --prefix-addresses --show-raw-insn
 #name: MIPS ELF NewABI jal
-#as: -n32 -KPIC -xgot
+#as: -march=mips3 -n32 -KPIC -xgot
 
 .*: +file format elf32-n.*mips.*
 
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/ldstla-n32-shared.d binutils-2.15.94-20050222/gas/testsuite/gas/mips/ldstla-n32-shared.d
--- binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/ldstla-n32-shared.d	2003-10-01 02:07:48.000000000 +0000
+++ binutils-2.15.94-20050222/gas/testsuite/gas/mips/ldstla-n32-shared.d	2005-02-11 19:05:06.000000000 +0000
@@ -1,5 +1,5 @@
 #objdump: -d
-#as: -KPIC -n32
+#as: -march=mips3 -KPIC -n32
 #name: MIPS ld-st-la constants (ABI n32, shared)
 #source: ldstla-n32.s
 
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/ldstla-n32.d binutils-2.15.94-20050222/gas/testsuite/gas/mips/ldstla-n32.d
--- binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/ldstla-n32.d	2003-10-01 02:07:48.000000000 +0000
+++ binutils-2.15.94-20050222/gas/testsuite/gas/mips/ldstla-n32.d	2005-02-11 19:04:45.000000000 +0000
@@ -1,5 +1,5 @@
 #objdump: -d
-#as: -n32
+#as: -march=mips3 -n32
 #name: MIPS ld-st-la constants (ABI n32)
 #source: ldstla-n32.s
 
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/ldstla-n64-shared.d binutils-2.15.94-20050222/gas/testsuite/gas/mips/ldstla-n64-shared.d
--- binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/ldstla-n64-shared.d	2004-01-09 02:24:23.000000000 +0000
+++ binutils-2.15.94-20050222/gas/testsuite/gas/mips/ldstla-n64-shared.d	2005-02-22 15:53:40.000000000 +0000
@@ -1,5 +1,5 @@
 #objdump: -d
-#as: -KPIC -64
+#as: -march=mips3 -KPIC -64
 #name: MIPS ld-st-la constants (ABI n64, shared)
 #source: ldstla-n64.s
 
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/ldstla-n64.d binutils-2.15.94-20050222/gas/testsuite/gas/mips/ldstla-n64.d
--- binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/ldstla-n64.d	2004-01-09 02:24:23.000000000 +0000
+++ binutils-2.15.94-20050222/gas/testsuite/gas/mips/ldstla-n64.d	2005-02-22 15:53:40.000000000 +0000
@@ -1,5 +1,5 @@
 #objdump: -d
-#as: -64
+#as: -march=mips3 -64
 #name: MIPS ld-st-la constants (ABI n64)
 #source: ldstla-n64.s
 
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/macro-warn-1-n32.d binutils-2.15.94-20050222/gas/testsuite/gas/mips/macro-warn-1-n32.d
--- binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/macro-warn-1-n32.d	2004-01-23 13:01:07.000000000 +0000
+++ binutils-2.15.94-20050222/gas/testsuite/gas/mips/macro-warn-1-n32.d	2005-02-22 15:53:40.000000000 +0000
@@ -1,4 +1,4 @@
-#as: -n32 -KPIC
+#as: -march=mips3 -n32 -KPIC
 #source: macro-warn-1.s
 #stderr: macro-warn-1-n32.l
 #objdump: -p
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/macro-warn-2-n32.d binutils-2.15.94-20050222/gas/testsuite/gas/mips/macro-warn-2-n32.d
--- binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/macro-warn-2-n32.d	2004-01-23 13:01:07.000000000 +0000
+++ binutils-2.15.94-20050222/gas/testsuite/gas/mips/macro-warn-2-n32.d	2005-02-22 15:53:40.000000000 +0000
@@ -1,4 +1,4 @@
-#as: -n32 -KPIC
+#as: -march=mips3 -n32 -KPIC
 #source: macro-warn-2.s
 #objdump: -p
 #pass
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/n32-consec.d binutils-2.15.94-20050222/gas/testsuite/gas/mips/n32-consec.d
--- binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/n32-consec.d	2003-01-27 23:01:55.000000000 +0000
+++ binutils-2.15.94-20050222/gas/testsuite/gas/mips/n32-consec.d	2005-02-11 19:03:50.000000000 +0000
@@ -1,4 +1,4 @@
-#as: -n32
+#as: -march=mips3 -n32
 #objdump: -Dr --prefix-addresses
 #name: n32 consecutive unrelated relocations
 
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/n32-consec.s binutils-2.15.94-20050222/gas/testsuite/gas/mips/n32-consec.s
--- binutils-2.15.94-20050222.macro/gas/testsuite/gas/mips/n32-consec.s	2003-01-27 23:01:55.000000000 +0000
+++ binutils-2.15.94-20050222/gas/testsuite/gas/mips/n32-consec.s	2005-02-11 20:34:51.000000000 +0000
@@ -1,4 +1,11 @@
 .text
 	.long .
+
+# align section end to 16-byte boundary for easier testing on multiple targets
+	.p2align 4
+
 .data
 	.long .+4
+
+# align section end to 16-byte boundary for easier testing on multiple targets
+	.p2align 4
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/ld/testsuite/ld-mips-elf/elf-rel-got-n32.d binutils-2.15.94-20050222/ld/testsuite/ld-mips-elf/elf-rel-got-n32.d
--- binutils-2.15.94-20050222.macro/ld/testsuite/ld-mips-elf/elf-rel-got-n32.d	2005-01-31 22:00:59.000000000 +0000
+++ binutils-2.15.94-20050222/ld/testsuite/ld-mips-elf/elf-rel-got-n32.d	2005-02-22 15:55:20.000000000 +0000
@@ -1,5 +1,5 @@
 #name: MIPS ELF got reloc n32
-#as: -EB -n32 -KPIC
+#as: -march=mips3 -EB -n32 -KPIC
 #source: ../../../gas/testsuite/gas/mips/elf-rel-got-n32.s
 #ld: -melf32btsmipn32
 #objdump: -D --show-raw-insn
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/ld/testsuite/ld-mips-elf/elf-rel-got-n64.d binutils-2.15.94-20050222/ld/testsuite/ld-mips-elf/elf-rel-got-n64.d
--- binutils-2.15.94-20050222.macro/ld/testsuite/ld-mips-elf/elf-rel-got-n64.d	2005-01-31 22:00:59.000000000 +0000
+++ binutils-2.15.94-20050222/ld/testsuite/ld-mips-elf/elf-rel-got-n64.d	2005-02-22 15:54:17.000000000 +0000
@@ -1,5 +1,5 @@
 #name: MIPS ELF got reloc n64
-#as: -EB -64 -KPIC
+#as: -march=mips3 -EB -64 -KPIC
 #source: ../../../gas/testsuite/gas/mips/elf-rel-got-n64.s
 #ld: -melf64btsmip
 #objdump: -D --show-raw-insn
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/ld/testsuite/ld-mips-elf/elf-rel-xgot-n32.d binutils-2.15.94-20050222/ld/testsuite/ld-mips-elf/elf-rel-xgot-n32.d
--- binutils-2.15.94-20050222.macro/ld/testsuite/ld-mips-elf/elf-rel-xgot-n32.d	2005-01-31 22:00:59.000000000 +0000
+++ binutils-2.15.94-20050222/ld/testsuite/ld-mips-elf/elf-rel-xgot-n32.d	2005-02-22 15:54:43.000000000 +0000
@@ -1,5 +1,5 @@
 #name: MIPS ELF xgot reloc n32
-#as: -EB -n32 -KPIC -xgot
+#as: -march=mips3 -EB -n32 -KPIC -xgot
 #source: ../../../gas/testsuite/gas/mips/elf-rel-got-n32.s
 #ld: -melf32btsmipn32
 #objdump: -D --show-raw-insn
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/ld/testsuite/ld-mips-elf/elf-rel-xgot-n64.d binutils-2.15.94-20050222/ld/testsuite/ld-mips-elf/elf-rel-xgot-n64.d
--- binutils-2.15.94-20050222.macro/ld/testsuite/ld-mips-elf/elf-rel-xgot-n64.d	2005-01-31 22:00:59.000000000 +0000
+++ binutils-2.15.94-20050222/ld/testsuite/ld-mips-elf/elf-rel-xgot-n64.d	2005-02-22 15:55:01.000000000 +0000
@@ -1,5 +1,5 @@
 #name: MIPS ELF xgot reloc n64
-#as: -EB -64 -KPIC -xgot
+#as: -march=mips3 -EB -64 -KPIC -xgot
 #source: ../../../gas/testsuite/gas/mips/elf-rel-got-n64.s
 #ld: -melf64btsmip
 #objdump: -D --show-raw-insn
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/ld/testsuite/ld-mips-elf/jalbal.d binutils-2.15.94-20050222/ld/testsuite/ld-mips-elf/jalbal.d
--- binutils-2.15.94-20050222.macro/ld/testsuite/ld-mips-elf/jalbal.d	2005-01-31 22:00:59.000000000 +0000
+++ binutils-2.15.94-20050222/ld/testsuite/ld-mips-elf/jalbal.d	2005-02-22 15:55:46.000000000 +0000
@@ -1,7 +1,7 @@
 #name: jal to bal
 #source: jalbal.s
 #as: -EB -n32 -march=rm9000
-#ld: -EB -e s1 -Ttext 0x100000a0
+#ld: -EB -e s1 -Ttext 0x100000a0 -melf32btsmipn32
 #objdump: -d
 
 .*file format elf.*mips.*
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/ld/testsuite/ld-mips-elf/relax-jalr-n32-shared.d binutils-2.15.94-20050222/ld/testsuite/ld-mips-elf/relax-jalr-n32-shared.d
--- binutils-2.15.94-20050222.macro/ld/testsuite/ld-mips-elf/relax-jalr-n32-shared.d	2003-09-21 16:40:29.000000000 +0000
+++ binutils-2.15.94-20050222/ld/testsuite/ld-mips-elf/relax-jalr-n32-shared.d	2005-02-11 19:07:44.000000000 +0000
@@ -1,6 +1,6 @@
 #name: MIPS relax-jalr-shared n32
 #source: relax-jalr.s
-#as: -KPIC -n32 -EB
+#as: -march=mips3 -KPIC -n32 -EB
 #objdump: --prefix-addresses -d --show-raw-insn
 #ld: --relax -shared -melf32btsmipn32
 
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/ld/testsuite/ld-mips-elf/relax-jalr-n32.d binutils-2.15.94-20050222/ld/testsuite/ld-mips-elf/relax-jalr-n32.d
--- binutils-2.15.94-20050222.macro/ld/testsuite/ld-mips-elf/relax-jalr-n32.d	2003-09-21 16:40:29.000000000 +0000
+++ binutils-2.15.94-20050222/ld/testsuite/ld-mips-elf/relax-jalr-n32.d	2005-02-11 19:07:48.000000000 +0000
@@ -1,6 +1,6 @@
 #name: MIPS relax-jalr n32
 #source: relax-jalr.s
-#as: -KPIC -n32 -EB
+#as: -march=mips3 -KPIC -n32 -EB
 #objdump: --prefix-addresses -d --show-raw-insn
 #ld: --relax -melf32btsmipn32
 
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/ld/testsuite/ld-mips-elf/relax-jalr-n64-shared.d binutils-2.15.94-20050222/ld/testsuite/ld-mips-elf/relax-jalr-n64-shared.d
--- binutils-2.15.94-20050222.macro/ld/testsuite/ld-mips-elf/relax-jalr-n64-shared.d	2003-09-21 16:40:29.000000000 +0000
+++ binutils-2.15.94-20050222/ld/testsuite/ld-mips-elf/relax-jalr-n64-shared.d	2005-02-11 19:07:51.000000000 +0000
@@ -1,6 +1,6 @@
 #name: MIPS relax-jalr-shared n64
 #source: relax-jalr.s
-#as: -KPIC -64 -EB
+#as: -march=mips3 -KPIC -64 -EB
 #objdump: --prefix-addresses -d --show-raw-insn
 #ld: --relax -shared -melf64btsmip
 
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/ld/testsuite/ld-mips-elf/relax-jalr-n64.d binutils-2.15.94-20050222/ld/testsuite/ld-mips-elf/relax-jalr-n64.d
--- binutils-2.15.94-20050222.macro/ld/testsuite/ld-mips-elf/relax-jalr-n64.d	2003-09-21 16:40:29.000000000 +0000
+++ binutils-2.15.94-20050222/ld/testsuite/ld-mips-elf/relax-jalr-n64.d	2005-02-11 19:07:54.000000000 +0000
@@ -1,6 +1,6 @@
 #name: MIPS relax-jalr n64
 #source: relax-jalr.s
-#as: -KPIC -64 -EB
+#as: -march=mips3 -KPIC -64 -EB
 #objdump: --prefix-addresses -d --show-raw-insn
 #ld: --relax -melf64btsmip
 
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/ld/testsuite/ld-mips-elf/reloc-1-n32.d binutils-2.15.94-20050222/ld/testsuite/ld-mips-elf/reloc-1-n32.d
--- binutils-2.15.94-20050222.macro/ld/testsuite/ld-mips-elf/reloc-1-n32.d	2003-12-18 10:25:12.000000000 +0000
+++ binutils-2.15.94-20050222/ld/testsuite/ld-mips-elf/reloc-1-n32.d	2005-02-22 15:53:40.000000000 +0000
@@ -1,5 +1,5 @@
-#source: reloc-1a.s -mabi=n32
-#source: reloc-1b.s -mabi=n32
+#source: reloc-1a.s -march=mips3 -mabi=n32
+#source: reloc-1b.s -march=mips3 -mabi=n32
 #ld: -r
 #readelf: --relocs
 
diff -up --recursive --new-file binutils-2.15.94-20050222.macro/ld/testsuite/ld-mips-elf/reloc-1-n64.d binutils-2.15.94-20050222/ld/testsuite/ld-mips-elf/reloc-1-n64.d
--- binutils-2.15.94-20050222.macro/ld/testsuite/ld-mips-elf/reloc-1-n64.d	2003-12-18 10:25:12.000000000 +0000
+++ binutils-2.15.94-20050222/ld/testsuite/ld-mips-elf/reloc-1-n64.d	2005-02-22 15:53:40.000000000 +0000
@@ -1,5 +1,5 @@
-#source: reloc-1a.s -mabi=64 -EB
-#source: reloc-1b.s -mabi=64 -EB
+#source: reloc-1a.s -march=mips3 -mabi=64 -EB
+#source: reloc-1b.s -march=mips3 -mabi=64 -EB
 #ld: -melf64btsmip -r
 #readelf: --relocs
 

Re: [PATCH] MIPS gas/ld test suite portability fixes

[Daniel Jacobowitz]

On Tue, Feb 22, 2005 at 06:22:01PM +0000, Maciej W. Rozycki wrote:
> Hello,
> 
>  It's generally unsafe to assume the default MIPS arch type will work for 
> NewABI tests (although it may happen to be the case with the targets that 
> currently enable them).  For example we get several failures with our SDE 
> toolchain if we configure it for mipsisa32-*.  I think it shouldn't hurt 
> to specify a compatible arch explicitly.
> 
>  We get failures due to a different alignment of sections, too.  Finally 
> one of the ld cases omits emulation specification, which may also lead to 
> a failure.

Adding an emulation will break the test on mips-sgi-irix6, which uses
different emulation names (and doesn't include the "traditional"
emulations).  jalbal used to pass on IRIX 6.

Not that I much care about the IRIX test results.  They're too much a
mess right now to be useful.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [PATCH] MIPS gas/ld test suite portability fixes

[Maciej W. Rozycki]

On Tue, 22 Feb 2005, Daniel Jacobowitz wrote:

> >  We get failures due to a different alignment of sections, too.  Finally 
> > one of the ld cases omits emulation specification, which may also lead to 
> > a failure.
> 
> Adding an emulation will break the test on mips-sgi-irix6, which uses
> different emulation names (and doesn't include the "traditional"
> emulations).  jalbal used to pass on IRIX 6.

 All other NewABI test cases pass an emulation option to ld.  I presume 
they currently fail for IRIX then, right?

> Not that I much care about the IRIX test results.  They're too much a
> mess right now to be useful.

 I can't really help with that, sorry.

  Maciej

Re: [PATCH] MIPS gas/ld test suite portability fixes

[Daniel Jacobowitz]

On Tue, Feb 22, 2005 at 06:39:31PM +0000, Maciej W. Rozycki wrote:
> On Tue, 22 Feb 2005, Daniel Jacobowitz wrote:
> 
> > >  We get failures due to a different alignment of sections, too.  Finally 
> > > one of the ld cases omits emulation specification, which may also lead to 
> > > a failure.
> > 
> > Adding an emulation will break the test on mips-sgi-irix6, which uses
> > different emulation names (and doesn't include the "traditional"
> > emulations).  jalbal used to pass on IRIX 6.
> 
>  All other NewABI test cases pass an emulation option to ld.  I presume 
> they currently fail for IRIX then, right?

Probably.  As I said:

> > Not that I much care about the IRIX test results.  They're too much a
> > mess right now to be useful.
> 
>  I can't really help with that, sorry.

Me either.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [PATCH] MIPS gas/ld test suite portability fixes

[Thiemo Seufer]

Maciej W. Rozycki wrote:
> Hello,
> 
>  It's generally unsafe to assume the default MIPS arch type will work for 
> NewABI tests (although it may happen to be the case with the targets that 
> currently enable them).  For example we get several failures with our SDE 
> toolchain if we configure it for mipsisa32-*.  I think it shouldn't hurt 
> to specify a compatible arch explicitly.
> 
>  We get failures due to a different alignment of sections, too.  Finally 
> one of the ld cases omits emulation specification, which may also lead to 
> a failure.
> 
>  Here's a fix that addresses these issues.  No regressions for 
> mips64-linux-gnu.
> 
> gas/testsuite/:
> 2005-02-22  Maciej W. Rozycki  <macro@mips.com>
> 
> 	* mips/elf-rel-got-n32.d: Pass -march=mips3 to gas to select a
> 	64-bit architecture.

We should probably change gas instead to imply MIPS III for -n32/-64.
It is the required minimum for NewABI anyways.


Thiemo

Re: [PATCH] MIPS gas/ld test suite portability fixes

[Maciej W. Rozycki]

On Tue, 22 Feb 2005, Thiemo Seufer wrote:

> > gas/testsuite/:
> > 2005-02-22  Maciej W. Rozycki  <macro@mips.com>
> > 
> > 	* mips/elf-rel-got-n32.d: Pass -march=mips3 to gas to select a
> > 	64-bit architecture.
> 
> We should probably change gas instead to imply MIPS III for -n32/-64.
> It is the required minimum for NewABI anyways.

 Hmm, in this case what about configurations that default to mips32 or 
mips32r2?  I wonder if -n32/-64 shouldn't actually imply the lowest 64-bit 
ISA higher than the default.  That would currently mean mips64 and 
mips64r2 for the mentioned cases, respectively, and mips3 otherwise.

  Maciej

Re: [PATCH] MIPS gas/ld test suite portability fixes

[Thiemo Seufer]

Maciej W. Rozycki wrote:
> On Tue, 22 Feb 2005, Thiemo Seufer wrote:
> 
> > > gas/testsuite/:
> > > 2005-02-22  Maciej W. Rozycki  <macro@mips.com>
> > > 
> > > 	* mips/elf-rel-got-n32.d: Pass -march=mips3 to gas to select a
> > > 	64-bit architecture.
> > 
> > We should probably change gas instead to imply MIPS III for -n32/-64.
> > It is the required minimum for NewABI anyways.
> 
>  Hmm, in this case what about configurations that default to mips32 or 
> mips32r2?  I wonder if -n32/-64 shouldn't actually imply the lowest 64-bit 
> ISA higher than the default.  That would currently mean mips64 and 
> mips64r2 for the mentioned cases, respectively, and mips3 otherwise.

I meant something like:

--- tc-mips.c   18 Feb 2005 22:12:50 -0000      1.284
+++ tc-mips.c   22 Feb 2005 21:54:59 -0000
@@ -10652,7 +10694,11 @@ mips_after_parse_args (void)
     }

   if (arch_info == 0)
-    arch_info = mips_parse_cpu ("default CPU", MIPS_CPU_STRING_DEFAULT);
+    {
+      arch_info = mips_parse_cpu ("default CPU", MIPS_CPU_STRING_DEFAULT);
+      if (ABI_NEEDS_64BIT_REGS (mips_abi) && !ISA_HAS_64BIT_REGS (arch_info->isa))
+       arch_info->isa = ISA_MIPS3;
+    }

   if (ABI_NEEDS_64BIT_REGS (mips_abi) && !ISA_HAS_64BIT_REGS (arch_info->isa))
     as_bad ("-march=%s is not compatible with the selected ABI",


(This fails to compile because arch_info is a constant.)


Thiemo

Re: [PATCH] MIPS gas/ld test suite portability fixes

[Eric Christopher]

> I meant something like:
> 
> --- tc-mips.c   18 Feb 2005 22:12:50 -0000      1.284
> +++ tc-mips.c   22 Feb 2005 21:54:59 -0000
> @@ -10652,7 +10694,11 @@ mips_after_parse_args (void)
>      }
> 
>    if (arch_info == 0)
> -    arch_info = mips_parse_cpu ("default CPU", MIPS_CPU_STRING_DEFAULT);
> +    {
> +      arch_info = mips_parse_cpu ("default CPU", MIPS_CPU_STRING_DEFAULT);
> +      if (ABI_NEEDS_64BIT_REGS (mips_abi) && !ISA_HAS_64BIT_REGS (arch_info->isa))
> +       arch_info->isa = ISA_MIPS3;
> +    }
> 
>    if (ABI_NEEDS_64BIT_REGS (mips_abi) && !ISA_HAS_64BIT_REGS (arch_info->isa))
>      as_bad ("-march=%s is not compatible with the selected ABI",
> 
> 
> (This fails to compile because arch_info is a constant.)

No, I definitely don't like this. It's going back to the era when
gcc/gas "guessed" what you meant. If we're passing an abi and don't have
a required minimum ISA either passed or by default then we should error
out.

-eric

Re: [PATCH] MIPS gas/ld test suite portability fixes

[Thiemo Seufer]

Eric Christopher wrote:
> 
> > I meant something like:
> > 
> > --- tc-mips.c   18 Feb 2005 22:12:50 -0000      1.284
> > +++ tc-mips.c   22 Feb 2005 21:54:59 -0000
> > @@ -10652,7 +10694,11 @@ mips_after_parse_args (void)
> >      }
> > 
> >    if (arch_info == 0)
> > -    arch_info = mips_parse_cpu ("default CPU", MIPS_CPU_STRING_DEFAULT);
> > +    {
> > +      arch_info = mips_parse_cpu ("default CPU", MIPS_CPU_STRING_DEFAULT);
> > +      if (ABI_NEEDS_64BIT_REGS (mips_abi) && !ISA_HAS_64BIT_REGS (arch_info->isa))
> > +       arch_info->isa = ISA_MIPS3;
> > +    }
> > 
> >    if (ABI_NEEDS_64BIT_REGS (mips_abi) && !ISA_HAS_64BIT_REGS (arch_info->isa))
> >      as_bad ("-march=%s is not compatible with the selected ABI",
> > 
> > 
> > (This fails to compile because arch_info is a constant.)
> 
> No, I definitely don't like this. It's going back to the era when
> gcc/gas "guessed" what you meant.

It is not a guess in this case, and gcc uses the from-abi hack to
figure it out correctly. Without it, e.g.

	gcc -mabi=64

would behave differently depending on its configuration. That's surely
counterintuitive and adds e.g. more breakage potential to Makefile
portability.

> If we're passing an abi and don't have
> a required minimum ISA either passed or by default then we should error
> out.

I agree it makes the ABI/ISA/ARCH/TUNE handling even more difficult,
but I think it's worth to also handle this transparently in the
assembler.


Thiemo

Re: [PATCH] MIPS gas/ld test suite portability fixes

[Eric Christopher]

> 
> It is not a guess in this case, and gcc uses the from-abi hack to
> figure it out correctly. Without it, e.g.
> 
> 	gcc -mabi=64
> 
> would behave differently depending on its configuration. That's surely
> counterintuitive and adds e.g. more breakage potential to Makefile
> portability.

As long as the arch is passed along as 'from-abi' I'm ok with changing
it. The problem with allowing people to just put -mabi=64 on a, say,
mips-linux-gnu compiler is that they may expect it's giving them, say,
mips4 code (I've heard it) and not mips3 code as you'd want to make it.

Having it error and make people be specific is the best bet I think, or
"from-abi" - at least that way they know that they're getting what we
choose :) As a note, we should probably document what "from-abi" is
giving people.

-eric

Re: [PATCH] MIPS gas/ld test suite portability fixes

[Thiemo Seufer]

Eric Christopher wrote:
> 
> > 
> > It is not a guess in this case, and gcc uses the from-abi hack to
> > figure it out correctly. Without it, e.g.
> > 
> > 	gcc -mabi=64
> > 
> > would behave differently depending on its configuration. That's surely
> > counterintuitive and adds e.g. more breakage potential to Makefile
> > portability.
> 
> As long as the arch is passed along as 'from-abi' I'm ok with changing
> it.

from-abi is always mips3 for NewABI.

> The problem with allowing people to just put -mabi=64 on a, say,
> mips-linux-gnu compiler is that they may expect it's giving them, say,
> mips4 code (I've heard it) and not mips3 code as you'd want to make it.

Mips4 is the default for the native IRIX ABI64 toolchain, gcc on IRIX
defaults to mips3 for ABI64, like Linux does. That's probably the
source of confusion here.

> Having it error and make people be specific is the best bet I think, or
> "from-abi" - at least that way they know that they're getting what we
> choose :)

They already specified it with -mabi, as mips3 is the minimum required
for NewABI.


Thiemo

Re: [PATCH] MIPS gas/ld test suite portability fixes

[Eric Christopher]

> > As long as the arch is passed along as 'from-abi' I'm ok with changing
> > it.
> 
> from-abi is always mips3 for NewABI.
> 

Right, I meant as long as they do this:

gas -march=from-abi -mabi=64

just as they would with a gcc that wasn't configured for the right
abi/isa.

> > The problem with allowing people to just put -mabi=64 on a, say,
> > mips-linux-gnu compiler is that they may expect it's giving them, say,
> > mips4 code (I've heard it) and not mips3 code as you'd want to make it.
> 
> Mips4 is the default for the native IRIX ABI64 toolchain, gcc on IRIX
> defaults to mips3 for ABI64, like Linux does. That's probably the
> source of confusion here.
> 

Undoubtedly.

> > Having it error and make people be specific is the best bet I think, or
> > "from-abi" - at least that way they know that they're getting what we
> > choose :)
> 
> They already specified it with -mabi, as mips3 is the minimum required
> for NewABI.

I think we're running into a difference between explicit command line
options and implicit. You think they implicitly implied mips3, I think
it was an error that they weren't explicit about what they wanted. :) 

As an example what if someone requested -32 on a toolchain that
defaulted to 64-bit? or, even better with a mips64-elf toolchain
specified -mips2? It defaults to o64, but yet mips2 isn't valid for the
abi.

I think if we allow -march=from-abi that'll solve the portable makefile
problem as well - as long as people specify the abi they want and let
from-abi say "gimme the abi, pick the minimum architecture required".

-eric

Re: [PATCH] MIPS gas/ld test suite portability fixes

[Thiemo Seufer]

Eric Christopher wrote:
> 
> > > As long as the arch is passed along as 'from-abi' I'm ok with changing
> > > it.
> > 
> > from-abi is always mips3 for NewABI.
> > 
> 
> Right, I meant as long as they do this:
> 
> gas -march=from-abi -mabi=64
> 
> just as they would with a gcc that wasn't configured for the right
> abi/isa.

Gcc does not behave that way for mips{,64}-linux, see MIPS_ISA_DEFAULT
and MIPS_CPU_STRING_DEFAULT. If neither is defined, the arch will be
figured out from the ABI. It would IMHO make no sense to fail on
"mips-linux-gcc -mabi=64" just because there's no arch specified.

mipsisa32*-linux fails because it defines MIPS_ISA_DEFAULT instead
of MIPS_CPU_STRING_DEFAULT.

Most of the mips*-elf targets define MIPS_ISA_DEFAULT, some define
additionally MIPS_CPU_STRING_DEFAULT.

Those gcc configurations should probably be changed to define
MIPS_CPU_STRING_DEFAULT only, with the ISA-generic default cpu value
for an ISA-specific config.

[snip]
> > > Having it error and make people be specific is the best bet I think, or
> > > "from-abi" - at least that way they know that they're getting what we
> > > choose :)
> > 
> > They already specified it with -mabi, as mips3 is the minimum required
> > for NewABI.
> 
> I think we're running into a difference between explicit command line
> options and implicit. You think they implicitly implied mips3, I think
> it was an error that they weren't explicit about what they wanted. :) 

No, I think they implied to get the minimum requirements for that ABI.

> As an example what if someone requested -32 on a toolchain that
> defaulted to 64-bit?

Without an arch specified, it defaults to the minimum needed: mips1.
Unless the toolchain config defines a default ISA, which disables
the ISA selection magic.

> or, even better with a mips64-elf toolchain
> specified -mips2? It defaults to o64, but yet mips2 isn't valid for the
> abi.

The -mipsX options are specialcased for historical reasons. Their
behaviour won't change by the proposed patch.

> I think if we allow -march=from-abi that'll solve the portable makefile
> problem as well - as long as people specify the abi they want and let
> from-abi say "gimme the abi, pick the minimum architecture required".

But we already have the information to fix the failure mode, and we
don't need to make any assumptions beyond this.


Thiemo

Re: [PATCH] MIPS gas/ld test suite portability fixes

[Thiemo Seufer]

Thiemo Seufer wrote:
[snip]
> > Right, I meant as long as they do this:
> > 
> > gas -march=from-abi -mabi=64
> > 
> > just as they would with a gcc that wasn't configured for the right
> > abi/isa.
> 
> Gcc does not behave that way for mips{,64}-linux, see MIPS_ISA_DEFAULT
> and MIPS_CPU_STRING_DEFAULT. If neither is defined, the arch will be
> figured out from the ABI. It would IMHO make no sense to fail on
> "mips-linux-gcc -mabi=64" just because there's no arch specified.
> 
> mipsisa32*-linux fails because it defines MIPS_ISA_DEFAULT instead
> of MIPS_CPU_STRING_DEFAULT.
> 
> Most of the mips*-elf targets define MIPS_ISA_DEFAULT, some define
> additionally MIPS_CPU_STRING_DEFAULT.
> 
> Those gcc configurations should probably be changed to define
> MIPS_CPU_STRING_DEFAULT only, with the ISA-generic default cpu value
> for an ISA-specific config.

This of course wouldn't change anything for the problem discussed
here, bacause any of both defines is enough to override the from-abi
selection. It would only avoid to have a (partial) duplicate ISA/CPU
table in the configuration script.

In the end we have two different approaches for ISA/ARCH selection,
a CPU-centric and an ABI-centric one. For the latter we want to have
sensible ISA defaults. This should be ok as long as we don't interfere
with the CPU-centric usage, which means elevating the ISA level to
the ABI requirement can be done, but lowering it from a higher level
can't.


Thiemo

Re: [PATCH] MIPS gas/ld test suite portability fixes

[Richard Sandiford]

Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
> Eric Christopher wrote:
>> > I meant something like:
>> > 
>> > --- tc-mips.c   18 Feb 2005 22:12:50 -0000      1.284
>> > +++ tc-mips.c   22 Feb 2005 21:54:59 -0000
>> > @@ -10652,7 +10694,11 @@ mips_after_parse_args (void)
>> >      }
>> > 
>> >    if (arch_info == 0)
>> > -    arch_info = mips_parse_cpu ("default CPU", MIPS_CPU_STRING_DEFAULT);
>> > +    {
>> > +      arch_info = mips_parse_cpu ("default CPU", MIPS_CPU_STRING_DEFAULT);
>> > +      if (ABI_NEEDS_64BIT_REGS (mips_abi) && !ISA_HAS_64BIT_REGS (arch_info->isa))
>> > +       arch_info->isa = ISA_MIPS3;
>> > +    }
>> > 
>> >    if (ABI_NEEDS_64BIT_REGS (mips_abi) && !ISA_HAS_64BIT_REGS (arch_info->isa))
>> >      as_bad ("-march=%s is not compatible with the selected ABI",
>> > 
>> > 
>> > (This fails to compile because arch_info is a constant.)
>> 
>> No, I definitely don't like this. It's going back to the era when
>> gcc/gas "guessed" what you meant.

Right.  I'm strongly with Eric here.

Eric's already mentioned the old gcc behaviour of -mabi=64 implying
-mips4, but remember that -mabi=32 also used to imply -mips1, on the
basis that that's what the SVR4 ABI officially requires.  But is that
what you want when you configure for sb1-elf or mipsisa32-elf?
How about when using mips64-linux-gnu configured with --with-arch=rm9000?
Should -mabi=32 override the --with-arch default?

Having -mabi change the architecture just leads to a mess.  There are
so many different possible interpretations.

You say:

> It is not a guess in this case, and gcc uses the from-abi hack to
> figure it out correctly.

but I don't see it as a hack at all.  It seems entirely consistent
with the idea that the architecture and ABI flags should be separate.
It was deliberately added as a separate architecture setting to cater
for the case where you always want the "most compatible" code possible.

And that's why it's the default for mips-* and mips64-* configurations
(meaning when --with-arch isn't used).  Those configurations don't
imply that you're using a particular processor.

Your proposal seems to be catering for the case where:

  (a) someone picks a 32-bit-only configuration that implies
      a particular architecture; and

  (b) then tries to use it to build 64-bit code.

Outside of running testsuites, who actually does that?  It's a minor
market, surely?  Anyone who's seriously interested in building 64-bit
code should use a 64-bit configuration, not something like mipstx39-elf,
mipsisa32-linux-gnu or whatever.  That's especially true when you
consider that a 32-bit-only configuration won't build any compatible
libraries.

The current option handling dates from mid 2002:

    http://sourceware.org/ml/binutils/2002-07/msg00463.html
    http://sourceware.org/ml/binutils/2002-07/msg00463.html

and the current policy was discussed at length in the follow-up
messages.  In particular, to quote from the second message:

--------------------------------------------------------------------------
6) The consensus seemed to be that, when using a configuration associated
   with a particular ISA or processor, we should try to stick to the
   default where possible.  So "mips64orion-elf-gcc -mabi=32" would
   generate 32-bit 4600 code rather than than MIPS I code.

   Then, we would only deviate from the default architecture when that
   architecture is a 32-bit one, and the selected ABI requires 64-bit
   registers.  For example, "mipstx39-elf -mabi=o64".  For configs
   like mipstx39-elf that are associated with a particular ISA, I
   think specifying an incompatible ABI should be a hard error.
   The user can of course say "mipstx39-elf -mabi=o64 -mips3" if
   that's what they truly mean.

   The question is, how do people see configs like mips-elf and
   mips64-elf?  Is mips-elf "a target for generating MIPS I code",
   or (by a weaker definition) "a target that generates 32-bit code
   by default".  Similarly mips64-elf, MIPS III and 64-bit code.

   According to the stronger definition, mips-elf-gcc would give
   an error if you pass -mabi=o64 without changing the architecture.
   According to the weaker definition, it should switch to MIPS III,
   since -mabi=o64 obviously overrides the "32-bit" default.  The
   stronger definition implies the default should be -march=mips1,
   while the weaker one implies it should be -march=from-abi.

   Same sort of question for mips64-elf.

   At the moment I'm leaning towards the weaker definition, so the patch
   makes "from-abi" the default for both.  Specifically, instead of
   setting MIPS_ISA_DEFAULT to 3 in elf64.h and 1 in mips.h, there is
   just a default definition of MIPS_CPU_STRING_DEFAULT as "from-abi".
   That means the default behaviour is to select the "most compatible"
   architecture for the given ABI, as Thiemo suggested.
--------------------------------------------------------------------------

As far as running the testsuite goes, I think we should either
apply something like Maciej's patch or simply disable these tests
for 32-bit configurations.

Richard

Re: [PATCH] MIPS gas/ld test suite portability fixes

[Thiemo Seufer]

Richard Sandiford wrote:
[snip]
> Eric's already mentioned the old gcc behaviour of -mabi=64 implying
> -mips4, but remember that -mabi=32 also used to imply -mips1, on the
> basis that that's what the SVR4 ABI officially requires.

IIRC it was first the other way: -mabi didn't exist, -mips1/2 implied
o32, -mips3 implied n32, and -mips4 implied n64. This emulated the IRIX
toolchain's behaviour, and was found to be inadequate for other mips
platforms. Then -mabi was added, and reverse-implied -mipsX, this
opened the door for several inconsistencies.

I don't want to follow that path, I only want -mabi to ensure it has
the minimum ABI requirement satisfied.

[snip]
> Your proposal seems to be catering for the case where:
> 
>   (a) someone picks a 32-bit-only configuration that implies
>       a particular architecture; and
> 
>   (b) then tries to use it to build 64-bit code.

This currently works for

	mips-linux-gcc -mabi=n32

thanks to from-abi but fails for

	mipsisa32-linux-gcc -mabi=n32

This inconsistency is introduced just because the toolchain's ISA
default is different to MIPS I.

> Outside of running testsuites, who actually does that? It's a minor
> market, surely?

With the market argument you can "prove" that there's no need for more
than one processor architecture. :-) But I agree, it is not a widely
used feature.

> Anyone who's seriously interested in building 64-bit
> code should use a 64-bit configuration, not something like mipstx39-elf,
> mipsisa32-linux-gnu or whatever. That's especially true when you
> consider that a 32-bit-only configuration won't build any compatible
> libraries.

Which is IMHO a bug in gcc, because -mabi=n?? should be fully usable.
(If this isn't true for some mips*-elf targets, then -mabi should
probably be an invalid option for these.)


Thiemo

Re: [PATCH] MIPS gas/ld test suite portability fixes

[Richard Sandiford]

Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
> Richard Sandiford wrote:
>> Your proposal seems to be catering for the case where:
>> 
>>   (a) someone picks a 32-bit-only configuration that implies
>>       a particular architecture; and
>> 
>>   (b) then tries to use it to build 64-bit code.
>
> This currently works for
>
> 	mips-linux-gcc -mabi=n32
>
> thanks to from-abi but fails for
>
> 	mipsisa32-linux-gcc -mabi=n32
>
> This inconsistency is introduced just because the toolchain's ISA
> default is different to MIPS I.

But the default architecture settings for _both_ configurations are
different from MIPS I.  The default architecture for mips-linux-gnu
is "from-abi", not "mips1".  Like I said in my earlier message:

>> [from-abi] was deliberately added as a separate architecture setting
>> to cater for the case where you always want the "most compatible"
>> code possible.
>>
>> And that's why it's the default for mips-* and mips64-* configurations
>> (meaning when --with-arch isn't used).  Those configurations don't
>> imply that you're using a particular processor.

See also the long quote from the 2002 message wrt whether mips-*
is a "MIPS I" configuration or a "32-bit configuration" by default.
We settled on a situation where mips-* is a "32-bit configuration"
by default.  In contrast, mipsisa32-*-* is a "MIPS32 configuration"
by default.  So if you use:

        mips-linux-gnu-gcc -mabi=64

then you're overriding the default 32-bitness.  You're selecting
-march=from-abi -mabi=64, which is well-defined.  But if you use:

        mipsisa32-linux-gnu-gcc -mabi=64

then you're _not_ overriding the default MIPS32ness, at least not
explicitly.  Should this command generate MIPS III or MIPS64 code?
Both are justifiable, and I personally would have expected MIPS64.

>> Anyone who's seriously interested in building 64-bit
>> code should use a 64-bit configuration, not something like mipstx39-elf,
>> mipsisa32-linux-gnu or whatever. That's especially true when you
>> consider that a 32-bit-only configuration won't build any compatible
>> libraries.
>
> Which is IMHO a bug in gcc, because -mabi=n?? should be fully usable.
> (If this isn't true for some mips*-elf targets, then -mabi should
> probably be an invalid option for these.)

And mips-linux-gnu, mipsisa32-linux-gnu, etc. as well, presumably?
We don't build n32 libraries for them either, and nor should we.

I don't buy that, but it's probably best not to go there ;)

Richard

Re: [PATCH] MIPS gas/ld test suite portability fixes

[Maciej W. Rozycki]

On Wed, 23 Feb 2005, Richard Sandiford wrote:

> I don't buy that, but it's probably best not to go there ;)

 I agree with you -- I think the "-mabi=" option is best left having no 
influence on "-march=".  OTOH, using mipsisa32-* tools for building n32 or 
(n)64 binaries may make sense, especially when done occasionally only 
which would not justify obtaining a full 64-bit setup.  It may even 
actually work for non-trivial builds as long as they are free-standing, 
including, but probably not limited to the Linux kernel.

  Maciej

Re: [PATCH] MIPS gas/ld test suite portability fixes

[Thiemo Seufer]

Richard Sandiford wrote:
[snip]
> >> Anyone who's seriously interested in building 64-bit
> >> code should use a 64-bit configuration, not something like mipstx39-elf,
> >> mipsisa32-linux-gnu or whatever. That's especially true when you
> >> consider that a 32-bit-only configuration won't build any compatible
> >> libraries.
> >
> > Which is IMHO a bug in gcc, because -mabi=n?? should be fully usable.
> > (If this isn't true for some mips*-elf targets, then -mabi should
> > probably be an invalid option for these.)
> 
> And mips-linux-gnu, mipsisa32-linux-gnu, etc. as well, presumably?
> We don't build n32 libraries for them either, and nor should we.

Why do we have -mabi then if it isn't supposed to be useful for
userland builds?


Thiemo

Re: [PATCH] MIPS gas/ld test suite portability fixes

[Richard Sandiford]

Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
> Richard Sandiford wrote:
>> >> Anyone who's seriously interested in building 64-bit
>> >> code should use a 64-bit configuration, not something like mipstx39-elf,
>> >> mipsisa32-linux-gnu or whatever. That's especially true when you
>> >> consider that a 32-bit-only configuration won't build any compatible
>> >> libraries.
>> >
>> > Which is IMHO a bug in gcc, because -mabi=n?? should be fully usable.
>> > (If this isn't true for some mips*-elf targets, then -mabi should
>> > probably be an invalid option for these.)
>> 
>> And mips-linux-gnu, mipsisa32-linux-gnu, etc. as well, presumably?
>> We don't build n32 libraries for them either, and nor should we.
>
> Why do we have -mabi then if it isn't supposed to be useful for
> userland builds?

Because we need -mabi for multi-ABI toolchains like mips64-linux-gnu,
mips-sgi-irix6.5, etc., and because it's easiest to support it
everywhere than to try to selectively enable it.

If the user knows what they're doing, and is prepared to accept the
limitations, then it can be useful.  Maciej's example of building a
64-bit kernel with mipsisa32-linux-gnu is a good example of that.
All I'm saying is that the user should expect to have to specify
the new architecture (the replacement for -mips32) in that sort
of situation.

Having every configuration accept -mabi is also useful for dejagnu
testing, just like it is in binutils.  It's also very useful for
debugging.

It would take quite a lot of extra code to get gcc itself to reject
-mabi switches for which no default libraries exist.  And what purpose
would it serve?  If the user tries to do the unsupported stuff, namely
link against libraries for a different ABI, then the linker itself will
complain.  Given the potentially useful applications of -mabi (such as
those listed above) making gcc reject the option outright just sounds
like pedantry.

Richard