I should clarify: it’s expected that there is a FunctionVal there. This is
much better when JITting later on, and the transform from FunctionVal to a
function pointer was a hack in IRForTarget.
The IRInterpreter just has to handle FunctionVals, as I just outlined.
Sean
> On Feb 24, 2016, at 2:36 PM, Sean Callanan via lldb-dev
> <lldb-dev@lists.llvm.org> wrote:
>
> 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 <ted.woodw...@codeaurora.org
>> <mailto:ted.woodw...@codeaurora.org>> 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: scalla...@apple.com <mailto:scalla...@apple.com>
>> [mailto:scalla...@apple.com <mailto:scalla...@apple.com>]
>> 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 <ted.woodw...@codeaurora.org
>>> <mailto:ted.woodw...@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: scalla...@apple.com <mailto:scalla...@apple.com>
>>> [mailto:scalla...@apple.com <mailto:scalla...@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.woodw...@codeaurora.org
>>>> <mailto:ted.woodw...@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
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
