http://sourceware.org/bugzilla/show_bug.cgi?id=12928
--- Comment #2 from Uros Bizjak <ubizjak at gmail dot com> 2011-06-24 09:09:31
UTC ---
I think that I got the problem, but the wrong relaxation is in main.
in an object, we have following part of test_code:
10: 00 00 5e b7 stq ra,0(sp)
14: 08 00 3e b5 stq s0,8(sp)
18: 09 04 f0 47 mov a0,s0
1c: 00 00 1d 22 lda a0,0(gp)
1c: TLSLDM fstat
20: 00 40 5b 6b jsr ra,(t12),24 <test_code+0x24>
20: LITUSE .text+0x5
20: HINT __tls_get_addr
24: 00 00 ba 27 ldah gp,0(ra)
24: GPDISP .text+0xc
28: 00 00 20 24 ldah t0,0(v0)
28: DTPRELHI fstat
2c: 00 00 5e a7 ldq ra,0(sp)
this links in the final link to:
1200007b0: 00 00 5e b7 stq ra,0(sp)
1200007b4: 08 00 3e b5 stq s0,8(sp)
1200007b8: 09 04 f0 47 mov a0,s0
=> 1200007bc: 10 00 1f 22 lda a0,16
1200007c0: 9e 00 00 00 rduniq
-> 1200007c4: 00 04 00 42 addq a0,v0,v0
1200007c8: 00 00 20 24 ldah t0,0(v0)
1200007cc: 00 00 5e a7 ldq ra,0(sp)
Please note the load of constant 16 (0x10) to a0. a0 is later added to v0.
However, in main, we have:
1c: 00 40 5b 6b jsr ra,(t12),20 <main+0x20>
1c: LITUSE .text.startup+0x3
1c: HINT test_code
20: 00 00 ba 27 ldah gp,0(ra)
20: GPDISP .text.startup+0x8
24: a1 55 00 40 cmpeq v0,0x2,t0
28: 00 00 bd 23 lda gp,0(gp)
2c: 09 04 e0 47 mov v0,s0
30: 0e 00 20 e4 beq t0,6c <main+0x6c>
34: 00 00 7d a7 ldq t12,0(gp)
34: ELF_LITERAL __tls_get_addr
38: 00 00 1d 22 lda a0,0(gp)
38: TLSLDM fstat
3c: 00 40 5b 6b jsr ra,(t12),40 <main+0x40>
3c: LITUSE .text.startup+0x5
3c: HINT __tls_get_addr
40: 00 00 ba 27 ldah gp,0(ra)
40: GPDISP .text.startup+0x8
44: 00 00 00 24 ldah v0,0(v0)
44: DTPRELHI fstat
48: 00 00 bd 23 lda gp,0(gp)
4c: 00 00 20 a0 ldl t0,0(v0)
4c: DTPRELLO fstat
this links in the final link to:
1200005dc: 72 00 40 d3 bsr ra,1200007a8 <test_code+0x8>
1200005e0: 00 00 fe 2f unop
1200005e4: a1 55 00 40 cmpeq v0,0x2,t0
1200005e8: 00 00 fe 2f unop
1200005ec: 09 04 e0 47 mov v0,s0
1200005f0: 0e 00 20 e4 beq t0,12000062c <main+0x6c>
=> 1200005f4: 10 00 7f 23 lda t12,16
1200005f8: 00 00 fe 2f unop
1200005fc: 9e 00 00 00 rduniq
-> 120000600: 00 04 00 42 addq a0,v0,v0
120000604: 00 00 00 24 ldah v0,0(v0)
120000608: 00 00 fe 2f unop
12000060c: 00 00 20 a0 ldl t0,0(v0)
Huh? Instead of loading a0 with 0x10, we load t12 instead, but a couple of
insns down the insn stream, we still add a0 to v0.
This also explains what happened when test_code clobbered a0. If the constant
value in a0, generated in test_code lived up to addq after the rduniq call in
main, everything worked ok, but by pure luck.
The linker should eventually update both instructions.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
