I think I understand what’s going on. The IR interpreter does this
[IRInterpreter.cpp:1573]:
–
// Find the address of the callee function
lldb_private::Scalar I;
const llvm::Value *val = call_inst->getCalledValue();
if (!frame.EvaluateValue(I, val, module))
{
error.SetErrorToGenericError();
error.SetErrorString("unable to get address of function");
return false;
}
–
It assumes that getCalledValue returns something we can evaluate – which used
to be a function pointer so everything was fine.
We have to modify EvaluateValue to, when it encounters a FunctionVal, look up
the corresponding symbol (using IRExecutionUnit::FindSymbol(), ideally) and
return a Scalar containing the function pointer.
As a first step, I’d suggest trying to make EvaluateValue return true but just
put nullptr into the Scalar when it gets a FunctionVal – does that result (as
I’d expect) in a bad function call, or do we still get some kind of “doesn’t
handle” error?
Sean
> On Feb 24, 2016, at 2:17 PM, Ted Woodward <[email protected]> wrote:
>
> I did some digging and found where the ID is being changed from 0x5 to 0xa in
> the original code.
>
> IRForTarget::runOnModule() calls ResolveFunctionPointers(), which gets a
> Constant * from BuildFunctionPointer(). This Value has an ID of 0xa, and
> runOnModule() then calls the original Function’s replaceAllUsesWith(),
> passing in the new Value, changing ID from 0x5 to 0xa.
>
> If I comment out the call to ResolveFunctionPointer() in the original code, I
> get the same error as the current code: “error: Can't run the expression
> locally: Interpreter doesn't handle one of the expression's operands”
>
> So I went to r260768 and added back in the call to ResolveFunctionPointer(),
> as well as functions that it depended on:
> ClangExpressionDeclMap::FindCodeSymbolInContext()
> ClangExpressionDeclMap::FindBestAlternateMangledName()
> ClangExpressionDeclMap::GetFunctionAddress()
> IRForTarget::GetFunctionAddress()
> IRForTarget::BuildFunctionPointer()
> I commented out the call to RegisterFunctionMetadata() since it didn’t seem
> to matter.
>
> After those changes, I was able to print out main’s info and call functions
> with the expression parser.
>
> Is there anything in these functions that I can get rid of, or is handled by
> newer code?
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
> From: [email protected] [mailto:[email protected]]
> Sent: Tuesday, February 23, 2016 6:38 PM
> To: Ted Woodward
> Cc: LLDB
> Subject: Re: r260768 (Removed many JIT workarounds from IRForTarget) broke
> expression parser with function on Hexagon
>
> 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 <[email protected]
>> <mailto:[email protected]>> 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: [email protected] <mailto:[email protected]>
>> [mailto:[email protected] <mailto:[email protected]>]
>> 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 <[email protected]
>>> <mailto:[email protected]>> 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
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
