[LLVMbugs] [Bug 13313] New: powerpc64 failures running llvmpipe / lp_test_* tests

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=13313

             Bug #: 13313
           Summary: powerpc64 failures running llvmpipe / lp_test_* tests
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: will_schmidt at vnet.ibm.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


> starting to investigate mesa/llvmpipe on powerpc
(powerpc64/power7) and hitting some issues trying to run the tests found
in mesa/src/gallium/drivers/llvmpipe/lp_test_*.   lp_test_arit,
lp_test_printf, lp_test_blend all seem to fail in similar fashion.

Configure and build are on a fedora 17 based power7 box, using mesa .git
HEAD as of today.  (3 Jul 2012)
[willschm at fuzzy mesa]$ ./autogen.sh --enable-gallium-llvm

< build steps trimmed >

[willschm at fuzzy mesa]$ cd src/gallium/drivers/llvmpipe
[willschm at fuzzy llvmpipe]$ ./lp_test_printf
Segmentation fault
[willschm at fuzzy llvmpipe]$ file ./lp_test_printf 
./lp_test_printf: ELF 64-bit MSB executable, 64-bit PowerPC or cisco
7500, version 1 (GNU/Linux), dynamically linked (uses shared libs), for
GNU/Linux 2.6.32,
BuildID[sha1]=0xb372fe4bb8536c54a3ac70df31537516ec7b8d2d, not stripped

build incantation for lp_test_printf looks like so:
g++  -L/usr/lib64/llvm  -lpthread -lffi -ldl -lm  lp_test_printf.o
lp_test_main.o -o lp_test_printf -Wl,--start-group  -L../../auxiliary/
-lgallium libllvmpipe.a -lLLVMBitWriter -lLLVMPowerPCCodeGen
-lLLVMSelectionDAG -lLLVMPowerPCDesc -lLLVMAsmPrinter -lLLVMMCParser
-lLLVMPowerPCAsmPrinter -lLLVMPowerPCInfo -lLLVMJIT
-lLLVMExecutionEngine -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine
-lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMMC
-lLLVMCore -lLLVMSupport  -lXext -lXdamage -lXfixes -lX11-xcb -lX11
-lxcb-glx -lxcb -lXxf86vm   -ldrm   -lm -lpthread -ldl -Wl,--end-group

A bit of time inside gdb:

Reading symbols
from
/home/willschm/llvm/mesa/src/gallium/drivers/llvmpipe/lp_test_printf...done.
(gdb) r
Starting
program: /home/willschm/llvm/mesa/src/gallium/drivers/llvmpipe/lp_test_printf 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x7c0802a6f8010010 in ?? ()
(gdb) bt
#0  0x7c0802a6f8010010 in ?? ()
#1  0x000000001001df40 in test_printf (gallivm=0x10a11e80, 
    testcase=<error reading variable: Unhandled dwarf expression opcode 0xfa>, 
    fp=<error reading variable: Unhandled dwarf expression opcode 0xfa>, 
    verbose=<error reading variable: Unhandled dwarf expression opcode 0xfa>)
at lp_test_printf.c:112
#2  0x000000001001e040 in test_all (fp=<optimized out>, verbose=<optimized
out>, gallivm=<optimized out>)
    at lp_test_printf.c:125
#3  test_some (gallivm=<optimized out>, verbose=<optimized out>, fp=<optimized
out>, n=<optimized out>)
    at lp_test_printf.c:135
#4  0x00000000100150e0 in main (argc=1, argv=<optimized out>) at
lp_test_main.c:401


Some single-step debug near the point of SIGSEGV suggests that we are
reading a bad pointer value off of $r3 and hit the segv on the btctr.  

Breakpoint 1, test_printf (gallivm=0x10a11e80, 
    testcase=<error reading variable: Unhandled dwarf expression opcode 0xfa>, 
    fp=<error reading variable: Unhandled dwarf expression opcode 0xfa>, 
    verbose=<error reading variable: Unhandled dwarf expression opcode 0xfa>)
at lp_test_printf.c:112
112        test_printf_func(0);
   0x000000001001df20 <test_printf+432>:        e9 43 00 00     ld     
r10,0(r3)
=> 0x000000001001df24 <test_printf+436>:        f8 41 00 28     std    
r2,40(r1)

(gdb) info reg r3
r3             0xfffb7f60010    17590977429520
(gdb) info reg r10
r10            0x7c0802a6f8010010       8937396376665391120

   0x000000001001df28 <test_printf+440>:        7c 69 1b 78     mr      r9,r3
   0x000000001001df2c <test_printf+444>:        38 60 00 00     li      r3,0
   0x000000001001df30 <test_printf+448>:        7d 49 03 a6     mtctr   r10
   0x000000001001df34 <test_printf+452>:        e9 69 00 10     ld     
r11,16(r9)
   0x000000001001df38 <test_printf+456>:        e8 49 00 08     ld     
r2,8(r9)
=> 0x000000001001df3c <test_printf+460>:        4e 80 04 21     bctrl


***
Subsequent discussion with BenH revealed:

> (gdb) info reg r3
> r3             0xfffb7f60010  17590977429520
> (gdb) info reg r10
> r10            0x7c0802a6f8010010     8937396376665391120

BenH points out to me that r10 value looks like code. 
 ppcdis 0x7c0802a6
mflr    r0

 ppcdis 0xf8010010
std     r0,16(r1)

So we are getting a pointer to the actual code, rather than a OPD
(function descriptor).

****

> Does llvm/examples/HowToUseJIT/HowToUseJIT.cpp work well there?
> 
> If so then you can take a look at lib/ExecutionEngine/JIT/JIT.cpp 's 
> JIT::runFunction method, and compare what's happening differently.

A build/run of HowToUseJIT behaved similarly.

g++ `llvm-config --ldflags` -o HowToUseJIT HowToUseJIT.o  `llvm-config --libs`
[willschm at fuzzy Release]$ ./HowToUseJIT 
We just constructed this LLVM module:

; ModuleID = 'test'
<snip...>
Running foo: Segmentation fault

****
Last comment on-list from Dave Arlie:
> I think the llvm ppc jits have been broken for quite a while since
> Apple stopped development on them, I suppose getting those working
> first would be the first step.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.