They're not supposed to go in the symbol table, and in fact the way the JIT
is currently implemented it sometimes crashes when you try to get the
address of such a function. So we skip them.
llvm-svn: 264821
quietly apply fixits for those who really trust clang's fixits.
Also, moved the retry into ClangUserExpression::Evaluate, where I can make a whole new ClangUserExpression
to do the work. Reusing any of the parts of a UserExpression in situ isn't supported at present.
<rdar://problem/25351938>
llvm-svn: 264793
This feature is controlled by an expression command option, a target property and the
SBExpressionOptions setting. FixIt's are only applied to UserExpressions, not UtilityFunctions,
those you have to get right when you make them.
This is just a first stage. At present the fixits are applied silently. The next step
is to tell the user about the applied fixit.
<rdar://problem/25351938>
llvm-svn: 264379
IRExecutionUnits contain code and data that persistent declarations can
depend on. In order to keep them alive and provide for lookup of these
symbols, we now allow any PersistentExpressionState to keep a list of
execution units. Then, when doing symbol lookup on behalf of an
expression, any IRExecutionUnit can consult the persistent expression
states on a particular Target to find the appropriate symbol.
<rdar://problem/22864976>
llvm-svn: 263995
a way for compilation to take a "thread to use for compilation". If it isn't set then the
compilation will use the currently selected thread. This should help keep function execution
to the one thread intended.
llvm-svn: 263972
We want to do a better job presenting errors that occur when evaluating
expressions. Key to this effort is getting away from a model where all
errors are spat out onto a stream where the client has to take or leave
all of them.
To this end, this patch adds a new class, DiagnosticManager, which
contains errors produced by the compiler or by LLDB as an expression
is created. The DiagnosticManager can dump itself to a log as well as
to a string. Clients will (in the future) be able to filter out the
errors they're interested in by ID or present subsets of these errors
to the user.
This patch is not intended to change the *users* of errors - only to
thread DiagnosticManagers to all the places where streams are used. I
also attempt to standardize our use of errors a bit, removing trailing
newlines and making clients omit 'error:', 'warning:' etc. and instead
pass the Severity flag.
The patch is testsuite-neutral, with modifications to one part of the
MI tests because it relied on "error: error:" being erroneously
printed. This patch fixes the MI variable handling and the testcase.
<rdar://problem/22864976>
llvm-svn: 263859
Summary:
From Adrian McCarthy:
"Running ninja check-lldb now has one crash in a Python process, due to deferencing a null pointer in IRExecutionUnit.cpp: candidate_sc.symbol is null, which leads to a call with a null this pointer."
Reviewers: zturner, spyffe, amccarth
Subscribers: ted, jingham, lldb-commits
Differential Revision: http://reviews.llvm.org/D17860
llvm-svn: 263066
The System-V x86_64 ABI requires floating point values to be passed
in 128-but SSE vector registers (xmm0, ...). When printing such a
variable this currently yields an <invalid load address>.
This patch makes LLDB's DWARF expression evaluator accept 128-bit
registers as scalars. It also relaxes the check that the size of the
result of the DWARF expression be equal to the size of the variable to a
greater-than. DWARF defers to the ABI how smaller values are being placed
in a larger register.
Implementation note: I found the code in Value::SetContext() that changes
the m_value_type after the fact to be questionable. I added a sanity check
that the Value's memory buffer has indeed been written to (this is
necessary, because we may have a scalar value in a vector register), but
really I feel like this is the wrong place to be setting it.
Reviewed by Greg Clayton.
http://reviews.llvm.org/D17897
rdar://problem/24944340
llvm-svn: 262947
Summary: Recent changes to the expression parser broke function name resolution when using the IR interpreter instead of JIT. This patch changes the IRMemoryMap ivar in InterpreterStackFrame to an IRExecutionUnitSP (which is a subclass), allowing InterpreterStackFrame::ResolveConstantValue() to call FindSymbol() on the name of the Value when it's a FunctionVal. It also changes IRExecutionUnit::FindInSymbols() to call GetFileAddress() on the symball if ResolveCallableAddress() fails and there is no valid Process.
Reviewers: spyffe
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D17745
llvm-svn: 262407
If we have a TargetLoadAddress on the top of the DWARF stack then a
DW_OP_plus or a DW_OP_plus_ucons sholudn't dereference (resolve) it
and then add the value to the dereferenced value but it should offset
the load address by the specified constant.
llvm-svn: 262339
The evaluation of expressions containing register values was broken for targets for which endianness differs from host.
Committed on behalf of: mamai <marianne.mailhot.sarrasin@gmail.com>
Differential revision: http://reviews.llvm.org/D17167
llvm-svn: 262041
Additionally fix the type of some dwarf expression where we had a
confusion between scalar and load address types after a dereference.
Differential revision: http://reviews.llvm.org/D17604
llvm-svn: 262014
IRExecutionUnit previously replicated a bunch of logic that already
existed elsewhere for the purpose of getting a load address for a
symbol. This approach failed to resolve certain types of symbols.
Instead, we now use functions on SymbolContext to do the address
resolution.
This is a cleanup of IRExecutionUnit::FindInSymbols, and also fixes a
latent bug where we looked at the wrong SymbolContext to determine
whether or not it is external.
<rdar://problem/24770829>
llvm-svn: 261704
the xcode project file to catch switch statements that have a
case that falls through unintentionally.
Define LLVM_FALLTHROUGH to indicate instances where a case has code
and intends to fall through. This should be in llvm/Support/Compiler.h;
Peter Collingbourne originally checked in there (r237766), then
reverted (r237941) because he didn't have time to mark up all the
'case' statements that were intended to fall through. I put together
a patch to get this back in llvm http://reviews.llvm.org/D17063 but
it hasn't been approved in the past week. I added a new
lldb-private-defines.h to hold the definition for now.
Every place in lldb where there is a comment that the fall-through
is intentional, I added LLVM_FALLTHROUGH to silence the warning.
I haven't tried to identify whether the fallthrough is a bug or
not in the other places.
I haven't tried to add this to the cmake option build flags.
This warning will only work for clang.
This build cleanly (with some new warnings) on macosx with clang
under xcodebuild, but if this causes problems for people on other
configurations, I'll back it out.
llvm-svn: 260930
Since IRExecutionUnit is now capable of looking up symbols, and the JIT is up to
the task of generating the appropriate relocations, we don't need to do all the
work that IRForTarget used to do to fixup symbols at the IR level.
We also don't need to allocate data manually (with its attendant bugs) because
the JIT is capable of doing so without crashing.
We also don't need the awkward lldb.call.realName metadata to determine what
calls are objc_msgSend, because they now just reference objc_msgSend.
To make this work, we ensure that we recognize which symbols are extern "C" and
report them to the compiler as such. We also report the full Decl of functions
rather than just making up top-level functions with the appropriate types.
This should not break any testcases, but let me know if you run into any issues.
<rdar://problem/22864926>
llvm-svn: 260768
Previously we would try both versions of a symbol -- the one with _ in it and
the one without -- in all cases, because we didn't know what the current
platform's policy was. However, stripping _ is only necessary on platforms
where _ is the prefix for global symbols.
There's an API that does this, though, on llvm::DataLayout, so this patch fixes
IRExecutionUnit to use that API to determine whether or not to strip _ from the
symbol or not.
llvm-svn: 260767
If an instruction has a constant that IRInterpreter doesn't know how to deal
with (say, an array constant, because we can't materialize it to APInt) then we
used to ignore that and only fail during expression execution. This is annoying
because if IRInterpreter had just returned false from CanInterpret(), the JIT
would have been used.
Now the IRInterpreter checks constants as part of CanInterpret(), so this should
hopefully no longer be an issue.
llvm-svn: 260735
I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a
dreadful hack working around no-longer-existing JIT bugs. Thanks to our
contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have,
so I've cleaned them up a bit and moved them over to IRExecutionUnit.
Also for historical reasons, IRExecutionUnit used the "Small" code model on non-
ELF platforms (namely, OS X). That's no longer necessary, and we can use the
same code model as everyone else on OS X. I've fixed that.
llvm-svn: 260734
Summary:
This reverts commit 8af14b5f9af68c31ac80945e5b5d56f0a14b38e4.
Reverting as it breaks a few tests on Mac.
Reviewers: spyffe
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16895
llvm-svn: 259823
Summary:
While evaluating expressions when stopped in a class method, there was a
problem of member variables hiding local variables. This was happening
because, in the context of a method, clang already knew about member
variables with their name and assumed that they were the only variables
with those names in scope. Consequently, clang never checks with LLDB
about the possibility of local variables with the same name and goes
wrong. This change addresses the problem by using an artificial
namespace "$__lldb_local_vars". All local variables in scope are
declared in the "$__lldb_expr" method as follows:
using $__lldb_local_vars::<local var 1>;
using $__lldb_local_vars::<local var 2>;
...
This hides the member variables with the same name and forces clang to
enquire about the variables which it thinks are declared in
$__lldb_local_vars. When LLDB notices that clang is enquiring about
variables in $__lldb_local_vars, it looks up local vars and conveys
their information if found. This way, member variables do not hide local
variables, leading to correct evaluation of expressions.
A point to keep in mind is that the above solution does not solve the
problem for one specific case:
namespace N
{
int a;
}
class A
{
public:
void Method();
int a;
};
void
A::Method()
{
using N::a;
...
// Since the above solution only touches locals, it does not
// force clang to enquire about "a" coming from namespace N.
}
Reviewers: clayborg, spyffe
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16746
llvm-svn: 259810
Seems that the patch was rebased on top of another change which obsoleted the
change but wasnt caught.
Thanks to nbjoerg for pointing this out!
llvm-svn: 258821
Address a couple of instances of -Wreturn-type warning from GCC. The switches
are covered, add an llvm_unreachable to the end of the functions to silence the
warning. NFC.
llvm-svn: 258546
SUMMARY:
The symbol "$" has a special meaning for MIPS i.e it is marker for temporary symbols for MIPS.
So this patch uses additional _ prefix for "$__lldb_valid_pointer_check" so that it wont be marked as temporary symbol in case of MIPS.
Reviewers: clayborg, spyffe
Subscribers: dean, emaste, mohit.bhakkad, sagar, jaydeep, lldb-commits
Differential http://reviews.llvm.org/D14111
llvm-svn: 258485
Zachary introduced the 'default' case explicitly to placate a warning in
the Microsoft compiler but that broke clang with -Werror.
The new code should keep both compilers happy.
llvm-svn: 258212
Summary:
DWARF 5 proposes a reinvented .debug_macro section. This change follows
that spec.
Currently, only GCC produces the .debug_macro section and hence
the added test is annottated with expectedFailureClang.
Reviewers: spyffe, clayborg, tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15437
llvm-svn: 255729
Summary:
Since this is within the lldb namespace, the compiler tries to
export a symbol for it. Unfortunately, since it is inlined, the
symbol is hidden and this results in a mess of warnings when
building on OS X with cmake.
Moving it to the lldb_private namespace eliminates that problem.
Reviewers: clayborg
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D14417
llvm-svn: 252396
callers had to do this by hand and we ended up never actually adding initial arguments and then
reusing them by passing in the struct address separately, so the distinction wasn't needed.
llvm-svn: 252108
The Go interpreter doesn't JIT or use LLVM, so this also
moves all the JIT related code from UserExpression to a new class LLVMUserExpression.
Differential Revision: http://reviews.llvm.org/D13073
Fix merge
llvm-svn: 251820
Jim Ingham