Bug 12610 - gas calculates wrong difference between two labels
Summary: gas calculates wrong difference between two labels
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: gas (show other bugs)
Version: 2.21
: P2 normal
Target Milestone: ---
Assignee: Richard Henderson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-28 18:40 UTC by Uros Bizjak
Modified: 2011-03-29 18:26 UTC (History)
1 user (show)

See Also:
Host:
Target: alpha-linux-gnu
Build:
Last reconfirmed:


Attachments
.s sources (958.07 KB, application/octet-stream)
2011-03-28 18:46 UTC, Uros Bizjak
Details
.o object files (590.38 KB, application/x-xz)
2011-03-28 18:49 UTC, Uros Bizjak
Details
.ii source (215.72 KB, application/x-xz)
2011-03-28 18:50 UTC, Uros Bizjak
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Uros Bizjak 2011-03-28 18:40:01 UTC
Following problem causes bootstrap comparison failure in gcc/go directory.

The two .s files are compiled from the same source:

types-2.s: ~/gcc-build-alpha/gcc/cc1plus -g -O2 -gtoggle -fno-common types.ii
types-3.s: ~/gcc-build-alpha/gcc/cc1plus -g -O2 -fno-common types.ii

types-2.o: alpha-linux-gnu-as types-2.s -o types-2.o
types-3.o: alpha-linux-gnu-as types-3.s -o types-3.o

The problem is in .gcc_except_table section.

For example, at offset 0x014e, the assembler calculates the difference of $LEHE25-$LEHB25 to 0x0c in case of types-2.o and to 0x08 in case of types-3.o. There are several similar failures, the total diference of .gcc_except_table section is:

-types-2.o:     file format elf64-alpha
+types-3.o:     file format elf64-alpha
 
@@ -10616,7 +10616,7 @@
  0120 00d00300 0000d401 00001000 00006004  ..............`.
  0130 000000fc 01000010 000000d0 03000000  ................
  0140 4c020000 b0000000 00000000 00c80300  L...............
- 0150 00080000 00d00300 0000f403 00000c00  ................
+ 0150 00080000 00d00300 0000f403 00000800  ................
  0160 00000000 00000010 04000008 000000d0  ................
  0170 03000000 58040000 68000000 00000000  ....X...h.......
  0180 00ffff03 1a440000 000c0000 00680000  .....D.......h..
@@ -10742,11 +10742,11 @@
  0900 50000000 10000000 00000000 006c0000  P............l..
  0910 00100000 00b80400 0000a000 00005804  ..............X.
  0920 00000000 000000ff ff038201 3c000000  ............<...
- 0930 f8000000 00000000 003c0100 00240300  .........<...$..
+ 0930 f8000000 00000000 003c0100 001c0300  .........<......
  0940 00100600 00006c04 00004400 00000000  ......l...D.....
  0950 000000cc 0400003c 00000010 06000000  .......<........
  0960 10050000 10000000 84070000 00440500  .............D..
- 0970 00b40000 00100600 00000806 00003800  ..............8.
+ 0970 00b40000 00100600 00000806 00003400  ..............4.
  0980 00000000 0000004c 0600000c 01000010  .......L........
  0990 06000000 5c070000 08000000 00000000  ....\...........
  09a0 00680700 00080000 00100600 00000000  .h..............
@@ -10816,7 +10816,7 @@
  0da0 00000008 05000010 00000038 0a000000  ...........8....
  0db0 24050000 10000000 240a0000 00480500  $.......$....H..
  0dc0 00100000 00d80900 0000a805 00001000  ................
- 0dd0 0000bc05 0000000c 06000014 00000000  ................
+ 0dd0 0000bc05 0000000c 06000008 00000000  ................
  0de0 00000000 34060000 44000000 bc050000  ....4...D.......
  0df0 008c0600 000c0000 00000000 0000a406  ................
  0e00 00006c01 0000bc05 00000030 08000010  ..l........0....
@@ -10860,7 +10860,7 @@
  1060 00001000 0000600b 00000068 0800003c  ......`....h...<
  1070 00000000 00000000 d8080000 10000000  ................
  1080 e40b0000 00f80800 00080000 00000900  ................
- 1090 00002409 00000c00 00000000 000000ff  ..$.............
+ 1090 00002409 00000800 00000000 000000ff  ..$.............
  10a0 ff03b601 a8000000 94000000 00000000  ................
  10b0 00400100 00100000 00200900 00005c01  .@....... ....\.
  10c0 00001000 0000dc08 000000b0 01000010  ................
@@ -10971,19 +10971,19 @@
  1750 ffff035b 78000000 10000000 00000000  ...[x...........
  1760 00900000 00840000 00d00200 0000a001  ................
  1770 0000b400 00000000 000000c8 02000008  ................
- 1780 000000d0 02000000 f4020000 0c000000  ................
+ 1780 000000d0 02000000 f4020000 08000000  ................
  1790 00000000 00180300 00880000 00d00200  ................
  17a0 0000a403 00004400 00000000 000000ff  ......D.........
  17b0 ff035b4c 000000d0 01000000 00000000  ..[L............
  17c0 28020000 5c000000 20050000 00400300  (...\... ....@..
  17d0 00780100 00000000 00001805 00000800  .x..............
- 17e0 00002005 00000044 0500000c 00000000  .. ....D........
+ 17e0 00002005 00000044 05000008 00000000  .. ....D........
  17f0 00000000 68050000 08000000 20050000  ....h....... ...
  1800 00740500 00340000 00000000 0000ffff  .t...4..........
  1810 038f0148 00000014 01000000 00000000  ...H............
  1820 dc010000 10000000 cc050000 00f40100  ................
  1830 005c0100 00f40400 00008003 00004401  .\............D.
- 1840 0000cc05 0000002c 05000014 00000000  .......,........
+ 1840 0000cc05 0000002c 05000008 00000000  .......,........
  1850 00000000 58050000 68000000 f4040000  ....X...h.......
  1860 00c40500 00080000 00cc0500 0000f805  ................
  1870 00000800 00000000 00000018 06000008  ................
@@ -11103,7 +11103,7 @@
  1f90 00001000 0000d409 000000fc 060000bc  ................
  1fa0 000000b0 08000000 e0070000 b8000000  ................
  1fb0 00000000 00a80800 00080000 00b00800  ................
- 1fc0 0000d408 00000c00 00000000 000000f0  ................
+ 1fc0 0000d408 00000800 00000000 000000f0  ................
  1fd0 08000020 000000b0 08000000 20090000  ... ........ ...
  1fe0 08000000 00000000 00700900 00080000  .........p......
  1ff0 00b00800 00007c09 0000e000 00000000  ......|.........

I have analysed the first occurrence of the error, at gcc_exception_table section, offset 0x014e. From the source file, this part represents the difference of $LEHE25-$LEHB25 in types-2.s:

	.text
	.align 2
	.align 4
	.globl _ZNK14Interface_type13do_reflectionEP4GogoPSs
	.ent _ZNK14Interface_type13do_reflectionEP4GogoPSs
_ZNK14Interface_type13do_reflectionEP4GogoPSs:
	.frame $30,96,$26,0
	.mask 0x400fe00,-96
...
$L1025:
	ldgp $29,0($26)
	mov $16,$9
$L1023:
	lda $16,80($30)
	jsr $26,_ZNSsD1Ev
	ldgp $29,0($26)
	mov $9,$16
$LEHB25:
	jsr $26,_Unwind_Resume
$LEHE25:
	.align 4
$L1032:
	lda $16,$LC0
	bis $31,$31,$31
	lda $17,6345($31)
	lda $18,_ZZNK14Interface_type13do_reflectionEP4GogoPSsE12__FUNCTION__
...
	.section	.gcc_except_table
$LLSDA4115:
	.byte	0xff
	.byte	0xff
	.byte	0x3
	.byte	0x8f,0x1
	.4byte	$LEHB17-$LFB4115
	.4byte	$LEHE17-$LEHB17
	.4byte	0
	.byte	0
	.4byte	$LEHB18-$LFB4115
	.4byte	$LEHE18-$LEHB18
	.4byte	$L1024-$LFB4115
	.byte	0
	.4byte	$LEHB19-$LFB4115
	.4byte	$LEHE19-$LEHB19
	.4byte	0
	.byte	0
	.4byte	$LEHB20-$LFB4115
	.4byte	$LEHE20-$LEHB20
	.4byte	$L1025-$LFB4115
	.byte	0
	.4byte	$LEHB21-$LFB4115
	.4byte	$LEHE21-$LEHB21
	.4byte	$L1026-$LFB4115
	.byte	0
	.4byte	$LEHB22-$LFB4115
	.4byte	$LEHE22-$LEHB22
	.4byte	$L1025-$LFB4115
	.byte	0
	.4byte	$LEHB23-$LFB4115
	.4byte	$LEHE23-$LEHB23
	.4byte	0
	.byte	0
	.4byte	$LEHB24-$LFB4115
	.4byte	$LEHE24-$LEHB24
	.4byte	$L1025-$LFB4115
	.byte	0
	.4byte	$LEHB25-$LFB4115
>>>	.4byte	$LEHE25-$LEHB25
	.4byte	0
	.byte	0
	.4byte	$LEHB26-$LFB4115
	.4byte	$LEHE26-$LEHB26
	.4byte	$L1025-$LFB4115
	.byte	0
	.4byte	$LEHB27-$LFB4115
	.4byte	$LEHE27-$LEHB27
	.4byte	0
	.byte	0
	.text
	.end _ZNK14Interface_type13do_reflectionEP4GogoPSs

The source in types-3.s referring to .gcc_except_table is the same, but due to debug info, there are many other labels in the .text section:

...
$LVL1697:
$L1025:
	ldgp $29,0($26)
	mov $16,$9
$LVL1698:
$L1023:
$LBE19894:
$LBE19895:
$LBE19896:
$LBE19954:
$LM1640:
	lda $16,80($30)
	jsr $26,_ZNSsD1Ev
	ldgp $29,0($26)
$LVL1699:
	mov $9,$16
$LEHB25:
	jsr $26,_Unwind_Resume
$LEHE25:
$LVL1700:
	.align 4
$L1032:
$LM1641:
	lda $16,$LC0
	bis $31,$31,$31
	lda $17,6345($31)
	lda $18,_ZZNK14Interface_type13do_reflectionEP4GogoPSsE12__FUNCTION__
...

However, object dump of .text section is always the same:

    53d4:	00 00 bd 23 	lda	gp,0(gp)
    53d8:	09 04 f0 47 	mov	a0,s0
    53dc:	50 00 1e 22 	lda	a0,80(sp)
    53e0:	00 00 7d a7 	ldq	t12,0(gp)
			53e0: ELF_LITERAL	_ZNSsD1Ev
    53e4:	00 40 5b 6b 	jsr	ra,(t12),53e8 <_ZNK14Interface_type13do_reflectionEP4GogoPSs+0x3e8>
			53e4: LITUSE	.text+0x3
			53e4: HINT	_ZNSsD1Ev
    53e8:	00 00 ba 27 	ldah	gp,0(ra)
			53e8: GPDISP	.text+0x4
    53ec:	00 00 bd 23 	lda	gp,0(gp)
    53f0:	10 04 e9 47 	mov	s0,a0
    53f4:	00 00 7d a7 	ldq	t12,0(gp)
			53f4: ELF_LITERAL	_Unwind_Resume
    53f8:	00 40 5b 6b 	jsr	ra,(t12),53fc <_ZNK14Interface_type13do_reflectionEP4GogoPSs+0x3fc>
			53f8: LITUSE	.text+0x3
			53f8: HINT	_Unwind_Resume
    53fc:	00 00 fe 2f 	unop	
    5400:	00 00 1d a6 	ldq	a0,0(gp)
			5400: ELF_LITERAL	.rodata
    5404:	1f 04 ff 47 	nop	
    5408:	c9 18 3f 22 	lda	a1,6345

This problem can be triggered with a cross-assembler from x86_64-linux-gnu to alpha-linux-gnu with attached .s files.
Comment 1 Uros Bizjak 2011-03-28 18:46:17 UTC
Created attachment 5332 [details]
.s sources
Comment 2 Uros Bizjak 2011-03-28 18:49:06 UTC
Created attachment 5333 [details]
.o object files
Comment 3 Uros Bizjak 2011-03-28 18:50:43 UTC
Created attachment 5334 [details]
.ii source
Comment 4 Richard Henderson 2011-03-29 17:16:25 UTC
Confirmed.  The label is getting attached to the end of the alignment,
rather than the beginning.  Examine the following with and without the
fixme label:

.text
	unop
	unop
	unop
	unop
$LEHB25:
	jsr	$26,_Unwind_Resume
$LEHE25:
$fixme:
	.align	4
	fnop

.data
	.long	$LEHE25 - $LEHB25

Somewhat amusingly, we get the correct answer *with* fixme present.

I have some vague rememberance that the old coff assembler had some
sort of auto-alignment feature, which got copied into the elf assembler.
I suspect this is what is causing the problem.
Comment 6 Richard Henderson 2011-03-29 18:26:33 UTC
Fixed.  More commentary at

http://sourceware.org/ml/binutils/2011-03/msg00525.html