[lldb-dev] r260768 (Removed many JIT workarounds from IRForTarget) broke expression parser with function on Hexagon

[Sean Callanan via lldb-dev]

At that point, I’d set a watchpoint and see what is setting it. I would expect that

  %call = call i32 @factorial(i32 5)

would put a normal value in call, which would then be the value stored by the store instruction

  store i32 %call, i32* @"_ZZ12$__lldb_exprPvE19$__lldb_expr_result", align 4

The store instruction should not have an operand of function type… right?

Sean

> On Feb 23, 2016, at 4:21 PM, Ted Woodward <ted.woodward at codeaurora.org> wrote:
> 
> Unfortunately, that leads to another error, in the Instruction::Store case. IRInterpreter::ResolveConstantValue() returns an error because it doesn’t like the value id of FunctionVal. “Interpreter couldn't resolve a value during execution”.
>  
> If I go back 1 commit from r260768 (r260767), it works. The value id is 0xa, ConstantIntVal. So something in r260768 is either setting the value id to 0x5, or keeping the value id from being set to 0xa.
>  
> Ted
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
>  
> From: scallanan at apple.com [mailto:scallanan at apple.com] 
> Sent: Tuesday, February 23, 2016 5:41 PM
> To: Ted Woodward
> Cc: LLDB
> Subject: Re: r260768 (Removed many JIT workarounds from IRForTarget) broke expression parser with function on Hexagon
>  
> Ted,
>  
> I’m not sure who inside Clang actually sets the value ID – it’s the code generator’s job to make IR, we don’t construct it.
> I would be fine with adding FunctionVal to the switch in CanResolveConstant, returning true.
>  
> Sean
>  
>> On Feb 23, 2016, at 3:28 PM, Ted Woodward <ted.woodward at codeaurora.org <mailto:ted.woodward at codeaurora.org>> wrote:
>>  
>> Background: Hexagon clang doesn’t have JIT support, so lldb for Hexagon only uses the IR Interpreter (Codeplay wrote it for us).
>>  
>> Sean, r260768 broke the expression parser with functions.
>>  
>> Without connecting to a target, I can’t get the info for main:
>> (lldb) e main
>> error: Can't run the expression locally: Interpreter doesn't handle one of the expression's operands
>>  
>> Connected to a target, I can’t run a function:
>> (lldb) e factorial(5)
>> error: Can't run the expression locally: Interpreter doesn't handle one of the expression's operands
>>  
>>  
>> I’ve traced the failure to the call to CanResolveConstant() in IRInterpreter::CanIntepret(). The failure happens on the 2nd operand. In the working case, the Value ID is 0xa – Value::ConstantExprVal. In the failing case, it is 0x5. Since it’s defined in a .def file, I can’t be sure, but my guess is its Value::FunctionVal.
>>  
>>  
>> Where is the Value ID set?
>>  
>>  
>>  
>> Some info from the expr log:
>>  
>> ; Function Attrs: nounwind
>> define void @"_Z12$__lldb_exprPv"(i8* %"$__lldb_arg") #0 {
>> entry:
>>   %"$__lldb_arg.addr" = alloca i8*, align 4, !clang.decl.ptr !4
>>   store i8* %"$__lldb_arg", i8** %"$__lldb_arg.addr", align 4
>>   %0 = load i8, i8* @"_ZGVZ12$__lldb_exprPvE19$__lldb_expr_result", align 1
>>   %guard.uninitialized = icmp eq i8 %0, 0
>>   br i1 %guard.uninitialized, label %init.check, label %init.end
>>  
>> init.check:                                       ; preds = %entry
>>   %call = call i32 @factorial(i32 5)
>>   store i32 %call, i32* @"_ZZ12$__lldb_exprPvE19$__lldb_expr_result", align 4
>>   store i8 1, i8* @"_ZGVZ12$__lldb_exprPvE19$__lldb_expr_result", align 1
>>   br label %init.end
>>  
>> init.end:                                         ; preds = %init.check, %entry
>>   ret void
>> }
>>  
>>  
>> Unsupported constant: declare i32 @factorial(i32) #1
>>  
>>  
>> Ted
>>  
>> --
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160223/f62827d8/attachment-0001.html>