[LLVMdev] Advice on debugging?

[Evan Cheng]

There is simply not enough information here to make an educated guess.  
But I'd say this is most likely not an optimization issue. Can you run  
lli in gdb to see where it is failing? Also you can add command line  
option -debug-only=jit. That should tell you which function is  
tripping lli up.

Evan

On Mar 31, 2008, at 8:54 PM, Talin wrote:

> Ping? Still looking for advice in figuring out how and why my  
> generated
> code is causing lli to crash...
>
> Talin wrote:
>> I've been using lli to do most of my unit tests for the compiler that
>> I'm writing. However, when I get a test that crashes, its difficult  
>> to
>> find which instruction it was that caused the crash. I tried running
>> bugpoint, but it didn't seem to work for me, and upon reading the
>> documentation, it seems to be intended for a different purpose than
>> finding bugs in my source program; It seems to be related more to
>> finding errors in the various optimizer passes.
>>
>> So for example, when I run lli on my program:
>> ----------------------------------------------------------
>> Assertion failed: (V == V2 && "Didn't find key?"), function  
>> RemoveKey,
>> file StringMap.cpp, line 177.
>> 0   lli                                 0x0049edcd
>> _ZN40_GLOBAL__N_Signals.cpp_00000000_B58D0A3815PrintStackTraceEv + 45
>> 1   lli                                 0x0049efc9
>> _ZN40_GLOBAL__N_Signals.cpp_00000000_B58D0A3813SignalHandlerEi + 323
>> 2   libSystem.B.dylib                   0x9534297b _sigtramp + 43
>> 3   ???                                 0xffffffff 0x0 + 4294967295
>> 4   libSystem.B.dylib                   0x953bb782 raise + 26
>> 5   libSystem.B.dylib                   0x953cad3f abort + 73
>> 6   libSystem.B.dylib                   0x953bc923 __assert_rtn + 101
>> 7   lli                                 0x00491ca7
>> _ZN4llvm13StringMapImpl9RemoveKeyEPNS_18StringMapEntryBaseE + 127
>> 8   lli                                 0x00461946
>> _ZN4llvm9StringMapIPNS_5ValueENS_15MallocAllocatorEE6removeEPNS_14StringMapEntryIS2_EE
>> + 24
>> 9   lli                                 0x00461094
>> _ZN4llvm16ValueSymbolTable15removeValueNameEPNS_14StringMapEntryIPNS_5ValueEEE
>> + 24
>> 10  lli                                 0x0040aabe
>> _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE18removeNodeFromListEPS1_
>> + 94
>> 11  lli                                 0x003cbd66
>> _ZN4llvm6iplistINS_10BasicBlockENS_12ilist_traitsIS1_EEE6removeERNS_14ilist_iteratorIS1_EE
>> + 254
>> ...etc...
>> ----------------------------------------------------------
>>
>> But when I run bugpoint, I get:
>> ----------------------------------------------------------
>> Read input file      : 'out/Debug/test/stdlib/test08.bcc'
>> *** All input ok
>> Found gcc: /usr/bin/gcc
>> Initializing execution environment: Running the code generator to  
>> test
>> for a crash: <cbe>
>> Generating reference output from raw program:
>> <cbe><cbe><gcc><program>Reference output is: bugpoint.reference.out
>>
>> *** Checking the code generator...
>> <cbe><gcc><program>
>> *** Debugging miscompilation!
>> Checking to see if '' compile correctly: <cbe><gcc><program> yup.
>> *** Optimized program matches reference output!  No problem  
>> detected...
>> bugpoint can't help you with your problem!
>> ----------------------------------------------------------
>>
>> To be honest, I am not sure what this all means.
>>
>> In any case, what I'd like is a way to find out more about the source
>> of the crash.
>>
>> I don't suppose anyone is working on a version of lli that supports
>> single-step debugging from the command line? Or do I need to compile
>> to assembly and use gdb? What's the best strategy for solving this
>> type of problem?
>>
>> -- Talin
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev