http://llvm.org/bugs/show_bug.cgi?id=21652
Bug ID: 21652
Summary: powerpc64le integrated assembler doesn't set correct
st_other bits on destructor symbols
Product: libraries
Version: trunk
Hardware: Other
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: PowerPC
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Classification: Unclassified
When I build the address sanitizer unit tests on powerpc64le Linux, I see this
oddness in one of the object files:
$ objdump -x
projects/compiler-rt/lib/asan/tests/ASAN_NOINST_TEST_OBJECTS.gtest-all.cc.powerpc64le-inline.o
| grep " _ZN7testing8internal2RED.Ev"
0000000000000000 g F .text._ZN7testing8internal2RED2Ev 0000000000000080
_ZN7testing8internal2RED1Ev
0000000000000000 g F .text._ZN7testing8internal2RED2Ev 0000000000000080
0x60 _ZN7testing8internal2RED2Ev
These two symbols are at the same address, but have different st_other bits.
These st_other bits tell you how to find the function's local entry point; 0x60
means that it's two instructions past the global entry point.
If you link this .o file with ld.bfd then the difference seems harmless, but if
you link with ld.gold then you get real problems: a local call to
_ZN7testing8internal2RED1Ev turns into a bl to the *global* entry point, but
r12 isn't set up properly. The causes the resulting executable
"Asan-powerpc64le-inline-Noinst-Test" to segfault.
A workaround is to compile with -no-integrated-as. Then both symbols get the
same st_other bits:
0000000000000000 g F .text._ZN7testing8internal2RED2Ev 0000000000000080
0x60 _ZN7testing8internal2RED2Ev
0000000000000000 g F .text._ZN7testing8internal2RED2Ev 0000000000000080
0x60 _ZN7testing8internal2RED1Ev
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
LLVMbugs mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
