Hi Paul,

Thank you for the help.

1. I managed to find the places in my code with the asm calls and
removed them. It turns out that I was incomplete in removing all the
asm calls.

2. I had hoped that switching to LLVM 3.0 would fix the problem, hence
the intrinsics. I switched back to LLVM 2.8, and combined with the
complete removal of the asm calls, I can now run KLEE on my target.

Thanks!
Jiaqi

On Thu, Feb 23, 2012 at 4:22 PM, Paul Marinescu
<[email protected]> wrote:
> Hi,
> You mention two unrelated issues:
> 1. inline assembly in LLVM code is generated if you have inline assembly in 
> your C code. The only way to get rid of it is by modifying the C code. 
> Optimization level is not relevant.
> 2. intrinsics such as llvm.uadd.with.overflow.* are generated by some 
> optimizer passes e.g., instruction combine (this is LLVM 2.9, other versions 
> may vary). The passes are either invoked by the compiler (-On) or by klee 
> (--optimize). If the bit code already contains them, --optimize=false won't 
> help.
>
> Paul
>
> On 23 Feb 2012, at 01:59, Jiaqi Tan wrote:
>
>> Hi,
>>
>> I guess I'm confused here. First, the problem is because LLVM
>> intrinsics are being generated into my bit-code? In that case, where
>> are the intrinsics being generated? Is it being generated by klee-gcc,
>> or llvm-gcc, or llvm-ld?
>>
>> I have tried doing "llvm-ld -disable-opt", and adding CFLAGS="-O0" to
>> my compilation, but I am still seeing the "call i[8|16|32|64] asm"
>> instructions in my (disassembled) bit-code. llvm-gcc doesn't have any
>> options for disabling optimization. If the bit-code already contains
>> the intrinsics, will doing "klee -optimize=false" help?
>>
>> Sorry I'm a bit confused here.
>>
>> Thanks,
>> Jiaqi
>>
>> On Wed, Feb 22, 2012 at 2:08 PM, Jiaqi Tan <[email protected]> wrote:
>>> Hi,
>>>
>>> It's still not working for me. Could this be because I'm using a
>>> version of LLVM that's too new? I've tried LLVM 2.8 and 3.0 and both
>>> aren't working. Sorry if this has been asked before, but what's the
>>> recommended version of LLVM to use with klee from trunk?
>>>
>>> Thanks,
>>> Jiaqi
>>>
>>> On Wed, Feb 22, 2012 at 1:55 PM, Paul Marinescu
>>> <[email protected]> wrote:
>>>> These intrinsics were added to LLVM after KLEE was released. Furthermore, 
>>>> you can avoid them by disabling the instruction combine pass (or 
>>>> --optimize=false altogether).
>>>>
>>>> Paul
>>>>
>>>>
>>>> On 22 Feb 2012, at 05:35, Jiaqi Tan wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I poked around a bit more. In general, does KLEE not support all LLVM
>>>>> intrinsics? Or does KLEE only not support certain intrinsics?
>>>>>
>>>>> I would believe that KLEE in general is able to support unsigned
>>>>> addition? I have encountered errors for unsupported
>>>>> llvm.uadd.with.overflow.i64 and .i32, so I'm puzzled about why that is
>>>>> the case.
>>>>>
>>>>> Thanks,
>>>>> Jiaqi
>>>>>
>>>>> On Wed, Feb 22, 2012 at 6:03 AM, Jiaqi Tan <[email protected]> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Thanks for the pointer.
>>>>>>
>>>>>> As for this error message:
>>>>>> WARNING: this target does not support the llvm.stacksave intrinsic.
>>>>>> LLVM ERROR: Code generator does not support intrinsic function
>>>>>> 'llvm.uadd.with.overflow.i64'!
>>>>>>
>>>>>> Is this also caused by unsupported inline asm? Apart from the __asm__
>>>>>> calls, are there any other C constructs that might generate inlined
>>>>>> asm?
>>>>>>
>>>>>> Thanks,
>>>>>> Jiaqi
>>>>>>
>>>>>> On Wed, Feb 22, 2012 at 1:02 AM, Paul Marinescu
>>>>>> <[email protected]> wrote:
>>>>>>> The error can be caused by an inline asm instruction in your program 
>>>>>>> (e.g.
>>>>>>> call i32 asm ...). KLEE does not support them.
>>>>>>>
>>>>>>> Paul
>>>>>>>
>>>>>>>
>>>>>>> On 21/02/12 09:46, Jiaqi Tan wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I did some poking around the KLEE source, and found that this error is
>>>>>>>> being generated due to the assertion here (code segment included):
>>>>>>>>
>>>>>>>> ===== begin code =====
>>>>>>>> const Cell&  Executor::eval(KInstruction *ki, unsigned index,
>>>>>>>>                            ExecutionState&state) const {
>>>>>>>>
>>>>>>>>   assert(index<  ki->inst->getNumOperands());
>>>>>>>>   int vnumber = ki->operands[index];
>>>>>>>>
>>>>>>>>   if (vnumber == -1) {
>>>>>>>>          std::cout<<  "Assert about to fail: #operands:"<<
>>>>>>>> ki->inst->getNumOperands()<<  " index:"<<  index<<  " vnumber:"<<
>>>>>>>> vnumber<<  std::endl;
>>>>>>>>   }
>>>>>>>>
>>>>>>>>   assert(vnumber != -1&&
>>>>>>>>          "Invalid operand to eval(), not a value or constant!");
>>>>>>>> ===== end code =====
>>>>>>>>
>>>>>>>> I suppose -1 is used as a special flag value here? Because later on,
>>>>>>>> (- vnumber - 2) is used to grab a constant 3 lines down in the code.
>>>>>>>> What does the operands array in KInstruction store, and where is it
>>>>>>>> populated?
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>> Jiaqi
>>>>>>>>
>>>>>>>> On Mon, Feb 20, 2012 at 1:52 PM, Jiaqi Tan<[email protected]>  
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I'm trying to run BusyBox, and I'm getting this error message:
>>>>>>>>>
>>>>>>>>> KLEE: WARNING: executable has module level assembly (ignoring)
>>>>>>>>> KLEE: WARNING: calling external: syscall(54, 0, 21505, 231590832)
>>>>>>>>> KLEE: WARNING: calling __user_main with extra arguments.
>>>>>>>>> KLEE: WARNING: calling external: __xstat64(3, 231196304, 231603064)
>>>>>>>>> klee: Executor.cpp:1001: const klee::Cell&
>>>>>>>>> klee::Executor::eval(klee::KInstruction*, unsigned int,
>>>>>>>>> klee::ExecutionState&) const: Assertion `vnumber != -1&&  "Invalid
>>>>>>>>>
>>>>>>>>> operand to eval(), not a value or constant!"' failed.
>>>>>>>>> 0  klee 0x089a79f8
>>>>>>>>> Aborted
>>>>>>>>>
>>>>>>>>> Does anybody have any idea where the source of the problem might be?
>>>>>>>>> I'm not quite sure where to get started to figure out where the
>>>>>>>>> problem is. Is this due to a compilation or linking problem due to
>>>>>>>>> missing code or libraries?
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>> Jiaqi Tan
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> klee-dev mailing list
>>>>>>>> [email protected]
>>>>>>>> http://keeda.Stanford.EDU/mailman/listinfo/klee-dev
>>>>>>>
>>>>>>>
>>>>
>
_______________________________________________
klee-dev mailing list
[email protected]
http://keeda.Stanford.EDU/mailman/listinfo/klee-dev

Reply via email to