I added this to ResolveConstantValue():
case Value::FunctionVal:
if (const Function *constant_func = dyn_cast<Function>(constant))
{
value = 0;
return true;
}
break;
value is an APInt &, so it won’t take nullptr.
“p main” returned the correct signature, but an address of 0.
“p factorial(5)” alternates between returning the parameter (5, in this case)
and an error, with the program restarting when it gets the error. _start on
Hexagon is 0, so my guess is lldb thought &factorial() was 0, so it set the pc
to there and continued. The error is “error: Supposed to interpret, but failed:
ThreadPlanCallFunctionUsingABI failed”. By half the time
Something interesting – constant_func->getName().str().c_str() gives “”. I’m
pretty sure I want to return the address of the function, but I’m not sure how
to get it.
--
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]
Sent: Wednesday, February 24, 2016 5:10 PM
To: Ted Woodward
Subject: Re: r260768 (Removed many JIT workarounds from IRForTarget) broke
expression parser with function on Hexagon
Yeah, I think we’ll have to return true in CanResolveConstant() for
FunctionVal, like you did as an experiment earlier.
Sean
On Feb 24, 2016, at 3:08 PM, Ted Woodward <ted.woodw...@codeaurora.org
<mailto:ted.woodw...@codeaurora.org> > wrote:
It never gets to IRInterpreter::Interpret(); it errors out in
IRInterpreter::CanInterpret(), in the call to CanResolveConstant() at line 656,
so it never calls getCalledValue() or EvaluateValue().
--
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]
Sent: Wednesday, February 24, 2016 4:36 PM
To: Ted Woodward
Cc: LLDB
Subject: Re: r260768 (Removed many JIT workarounds from IRForTarget) broke
expression parser with function on Hexagon
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 <
<mailto:ted.woodw...@codeaurora.org> 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: <mailto:scalla...@apple.com> 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 <
<mailto:ted.woodw...@codeaurora.org> 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: <mailto:scalla...@apple.com> 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 <
<mailto:ted.woodw...@codeaurora.org> 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
