Re: status of gold for ARM

[Roland McGrath <mcgrathr at google dot com>]

The trunk is now good but on binutils-2_25-branch (eddde7f) I am now getting:
	FAIL: arm_unaligned_reloc.sh

Make sure you do clean builds to compare.  The actual problem comes from
objdump treating gold/testsuite/arm_unaligned_reloc_r differently for the
two branches.  In fact, objdump is behaving the same (odd) way in both
branches, but its output differs (for no good reason) between the files
generated in the two branches.  The real difference is in the assembler,
which in 2.25 produces .data.0 and .data.1 sections with just their
explicit sizes (4, 13), while in the trunk it produces .data.0 and .data.1
sections that are padded out to their sh_addralign sizes (both 4096).

For the unpadded sections (arm_unaligned_reloc_r from 2.25), objdump -Dr
produces:
	Disassembly of section .data.0:

	00000000 <x>:
	       0:	00000001 	andeq	r0, r0, r1
		...

	Disassembly of section .data.1:

	00000000 <padding>:
		...

	00000001 <abs32>:
*	       1:	00000000 	andeq	r0, r0, r0
				1: R_ARM_ABS32	.data.0

	00000005 <rel32>:
*	       5:	00000000 	andeq	r0, r0, r0
				5: R_ARM_REL32	.data.0

	00000009 <abs16>:
**		...
				9: R_ARM_ABS16	.data.0

whereas for the padded sections (arm_unaligned_reloc_r from trunk), the
same objdump -Dr produces:
	Disassembly of section .data.0:

	00000000 <x>:
	   0:	00000001 	andeq	r0, r0, r1

	Disassembly of section .data.1:

	00000000 <padding>:
		...

	00000001 <abs32>:
*	   1:	00000000 	andeq	r0, r0, r0
				1: R_ARM_ABS32	.data.0

	00000005 <rel32>:
*	   5:	00000000 	andeq	r0, r0, r0
				5: R_ARM_REL32	.data.0

	00000009 <abs16>:
**	   9:	00000000 	andeq	r0, r0, r0
				9: R_ARM_ABS16	.data.0

The differences are the indentation on the lines marked with *, and the
choice of disassembling a zero word vs "..." on the line marked with **.
I don't know why objdump does that, or if it's intended to.

I don't know if that difference in the assembler was an intended change on
the trunk or not.

Regardless, none it actually has anything to do with what's being tested in
gold.  As things stand, arm_unaligned_reloc.sh is also inconsistent between
disassembly lines and reloc lines as to whether it matches the indentation
precisely or loosely.  So its regexps could just be changed to be looser
about its matching and then these details of gas and objdump behavior would
not affect the gold test suite one way or the other.


Thanks,
Roland