Closed Quuxplusone closed 7 years ago
Bugzilla Link | PR33825 |
Status | RESOLVED FIXED |
Importance | P normal |
Reported by | Fedor Sergeev (fedor.v.sergeev@gmail.com) |
Reported on | 2017-07-17 14:50:21 -0700 |
Last modified on | 2017-07-25 12:56:19 -0700 |
Version | trunk |
Hardware | Sun All |
CC | llvm-bugs@lists.llvm.org |
Fixed by commit(s) | |
Attachments | |
Blocks | |
Blocked by | |
See also |
For this code gcc generates:
] g++ tls-hix.cc -std=c++11 -m64 -c; elfdump -r tls-hix.o | grep TLS
[0] R_SPARC_TLS_LE_HIX22 0x4 0 0 .text _ZL14StackTraceHead
[1] R_SPARC_TLS_LE_LOX10 0x8 0 0 .text _ZL14StackTraceHead
]
And clang generates:
] bin/clang++ tls-hix.cc -std=c++11 -m64 -c; elfdump -r tls-hix.o | grep TLS
[0] R_SPARC_TLS_LE_HIX22 0x1c 0x3fffff 0 .text _ZL14StackTraceHead
[1] R_SPARC_TLS_LE_LOX10 0x20 0x1c00 0 .text _ZL14StackTraceHead
]
Something is clearly wrong with values here...
Hmm... I'm not sure what I did wrong in the above, but it strangely messes up
LDO and LE relocations. Anyway, both LDO and LE have problems, LDO_HIX22 used
for PIC code and LE_HIX22 for non-PIC one.
In Oracle's (former Sun) "Linker and Libraries Guide", its "SPARC: Thread-Local
Storage Relocation Types" subsection, this relocation is being defined as:
R_SPARC_TLS_LDO_HIX22 T-simm22 @dtpoff(S + A) >> 10
R_SPARC_TLS_LE_HIX22 T-imm22 (@tpoff(S + A) ^0xffffffffffffffff) >> 10
If I read it right this is what linker should be doing when given Symbol (S)
and Addend (A). And Value is not present there at all.
Yet the code in lib/Target/Sparc/MCTargetDesc/SparcAsmBackend.cpp seems to be
doing some nontrivial fixups for the Value:
case Sparc::fixup_sparc_tls_ldo_hix22:
case Sparc::fixup_sparc_tls_le_hix22:
return (~Value >> 10) & 0x3fffff;
I believe this fixup should just be deleted.
https://reviews.llvm.org/D35567 solves this problem for me.
Fixed with:
rL308978: [Sparc] invalid adjustments in TLS_LE/TLS_LDO relocations removed