[PATCH] [PowerPC] Fix __tls_get_addr sequence to avoid register assignment issues
hfinkel at anl.gov
hfinkel at anl.gov
Sun Feb 8 17:35:18 PST 2015
Alright, here's what happening on the `P7`:
Starting program: /home/hfinkel/build/ppc64/llvm-stage1/bin/clang-tblgen -gen-arm-neon -I /home/hfinkel/src/llvm/tools/clang/lib/Headers -I /home/hfinkel/src/llvm/lib/Target -I /home/hfinkel/src/llvm/include /home/hfinkel/src/llvm/tools/clang/include/clang/Basic/arm_neon.td -o /home/hfinkel/build/ppc64/llvm-stage1/tools/clang/lib/Headers/arm_neon.h.tmp
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x000000001008d2a4 in .llvm::PrettyStackTraceEntry::PrettyStackTraceEntry() ()
(gdb) disassemble
Dump of assembler code for function ._ZN4llvm21PrettyStackTraceEntryC2Ev:
0x000000001008d270 <+0>: mflr r0
0x000000001008d274 <+4>: std r31,-8(r1)
0x000000001008d278 <+8>: std r0,16(r1)
0x000000001008d27c <+12>: stdu r1,-64(r1)
0x000000001008d280 <+16>: addis r12,r2,-1
0x000000001008d284 <+20>: nop
0x000000001008d288 <+24>: mr r4,r3
0x000000001008d28c <+28>: mr r31,r1
0x000000001008d290 <+32>: addi r3,r2,-32392
0x000000001008d294 <+36>: addi r6,r12,-2248
0x000000001008d298 <+40>: bl 0x10005078 <00000011.plt_call.__tls_get_addr@@GLIBC_2.3+0>
0x000000001008d29c <+44>: ld r2,40(r1)
0x000000001008d2a0 <+48>: addi r5,r6,16
=> 0x000000001008d2a4 <+52>: std r5,0(r4)
0x000000001008d2a8 <+56>: addis r3,r3,0
0x000000001008d2ac <+60>: ori r2,r2,0
0x000000001008d2b0 <+64>: ld r5,-32768(r3)
0x000000001008d2b4 <+68>: std r5,8(r4)
0x000000001008d2b8 <+72>: std r4,-32768(r3)
0x000000001008d2bc <+76>: addi r1,r1,64
0x000000001008d2c0 <+80>: ld r0,16(r1)
0x000000001008d2c4 <+84>: ld r31,-8(r1)
0x000000001008d2c8 <+88>: mtlr r0
0x000000001008d2cc <+92>: blr
0x000000001008d2d0 <+96>: .long 0x0
0x000000001008d2d4 <+100>: .long 0x0
0x000000001008d2d8 <+104>: .long 0x0
End of assembler dump.
Looks to me like the instruction that becomes the function call needs to do more than clobber r3. Maybe it needs the full clobber mask associated with a regular function call? Based on this crash, it looks like it at least also clobbers r4.
http://reviews.llvm.org/D7491
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
More information about the llvm-commits
mailing list