Mips64 tests were failing on windows because the sscanf implementation differs between clang/gcc/msvc such that on windows %lx specifies a 32bits parameter and %llx is for 64bits. For us this meant that 64bit pointers were being truncated to 32bits on their way into a JIT'd expression.
llvm-svn: 261741
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
Summary:
On arm64, linux<=4.4 and Android<=M there is a bug, which prevents single-stepping from working when
the system comes back from suspend, because of incorrectly initialized CPUs. This did not really
affect Android<M, because it did not use software suspend, but it is a problem for M, which uses
suspend (doze) quite extensively. Fortunately, it seems that the first CPU is not affected by
this bug, so this commit implements a workaround by forcing the inferior to execute on the first
cpu whenever we are doing single stepping.
While inside, I have moved the implementations of Resume() and SingleStep() to the thread class
(instead of process).
Reviewers: tberghammer, ovyalov
Subscribers: aemerson, rengolin, tberghammer, danalbert, srhines, lldb-commits
Differential Revision: http://reviews.llvm.org/D17509
llvm-svn: 261636
Summary:
Signalfd is not used in the code anymore, and given that the same functionality can be achieved
with the new MainLoop class, it's unlikely we will need it in the future. Remove all traces of
it.
Reviewers: tberghammer, ovyalov
Subscribers: tberghammer, danalbert, srhines, lldb-commits
Differential Revision: http://reviews.llvm.org/D17510
llvm-svn: 261631
Inline functions in DWARF have AT_abstract_origin set, but we only handled that
if the functions were C++ methods. Inline functions -- C or C++ -- have this
also, and as a result they got one FunctionDecl for each inlined instance. When
going to construct the locals, this meant that the arguments (which did properly
have their abstract origins handled) would get associated with the master
FunctionDecl, and the inlined FunctionDecls would all appear to have no locals.
This manifested as not being able to look up local variables when stopped in an
inline fuunction. We should have had a test for this, but somewhere along the
line the relevant test case lost its .py file (or it never had one).
This patch fixes this problem and restores the .py file.
<rdar://problem/24712434>
llvm-svn: 261598
This patch aims to reduce the code duplication among all of the platforms in GetSoftwareBreakpointTrapOpcode by pushing all common code into the Platform base class.
Differential Revision: http://reviews.llvm.org/D17395
llvm-svn: 261536
This patches does the following:
+ fix return type: ClangExpressionParser::Parse returns unsigned, but was actually returning a signed value, num_errors.
+ use helper clang::TextDiagnosticBuffer::getNumErrors() instead of counting the errors ourself.
+ limit scoping of block-level automatic variables as much as practical.
+ remove reused multipurpose TextDiagnosticBuffer::const_iterator in favour of loop-scoped err, warn, and note variables in the diagnostic printing code.
+ refactor diagnostic printing loops to use a proper loop invariant.
Author: Luke Drummond <luke.drummond@codeplay.com>
Differential Revision: http://reviews.llvm.org/D17273
llvm-svn: 261345
There is a report in the PR from several months ago that it failed
intermittently, but it is passing consistently for me on FreeBSD 10
and 11. We can re-add a decorator if further testing shows it is
still flakey.
llvm.org/pr17214
llvm-svn: 261340
Both Linux and FreeBSD had a comment "This needs to be root-caused."
It looks like the failure has been fixed on both, and the Linux XFAIL
decorator was removed in r233716 (Mar 2015).
llvm-svn: 261333
[git 65dafa83] introduced the GetBuiltinIncludePath function copied from cfe/lib/Driver/CC1Options.cpp
This function is no longer used in lldb's expression parser and I believe it is safe to remove it.
Author: Luke Drummond <luke.drummond@codeplay.com>
Differential Revision: http://reviews.llvm.org/D17266
llvm-svn: 261328
This change is improving the instruction emulation based unwinding to
handle when the frame pointer is adjusted (increment/decrement) after
it has been initialized. The situation can occur in the prologue of
some function where FP is adjusted before it is copied back to SP.
Example code (thumb, generated by gcc 4.8):
< +0>: push {r4, r7, lr}
< +2>: sub sp, #0x14
< +4>: add r7, sp, #0x0
...
<+50>: adds r7, #0x14 ; The CL fixes the handling of this instruction
<+52>: mov sp, r7 ; Previously unwinding from here was broken
<+54>: pop {r4, r7, pc}
Differential revision: http://reviews.llvm.org/D17295
llvm-svn: 261318
working directory by default -- a typical security problem that we
need to be more conservative about.
It adds a new target setting, target.load-cwd-lldbinit which may
be true (always read $cwd/.lldbinit), false (never read $cwd/.lldbinit)
or warn (warn if there is a $cwd/.lldbinit and don't read it). The
default is set to warn. If this is met with unhappiness, we can look
at changing the default to true (to match current behavior) on a
different platform.
This does not affect reading of ~/.lldbinit - that will still be read,
as before. If you run lldb in your home directory, it will not warn
about the presence of a .lldbinit file there.
I had to add two SB API - SBHostOS::GetUserHomeDirectory and
SBFileSpec::AppendPathComponent - for the lldb driver code to be
able to get the home directory path in an OS neutral manner.
The warning text is
There is a .lldbinit file in the current directory which is not being read.
To silence this warning without sourcing in the local .lldbinit,
add the following to the lldbinit file in your home directory:
settings set target.load-cwd-lldbinit false
To allow lldb to source .lldbinit files in the current working directory,
set the value of this variable to true. Only do so if you understand and
accept the security risk.
<rdar://problem/24199163>
llvm-svn: 261280
on attach uses the architecture it has figured out, rather than the Target's
architecture, which may not have been updated to the correct value yet.
<rdar://problem/24632895>
llvm-svn: 261279
The race condition/use after free involved in setting long prompts
appears to be fixed now (although I do not know which commit fixed it).
llvm.org/pr22611
llvm-svn: 261266
Commit r260721(http://reviews.llvm.org/D17182) introduced the following error when building for OSX using cmake:
Undefined symbols for architecture x86_64:
"_PyInit__lldb", referenced from:
-exported_symbol[s_list] command line option
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Adding '*' to the regex solves this problem, since it makes the symbol optional.
Reviewers: sivachandra, zturner, labath
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D17384
llvm-svn: 261227
SUMMARY:
This patch implements ArchSpec::GetClangTargetCPU() that provides string representing current architecture as a target CPU.
This string is then passed to tools like clang so that they generate correct code for that target.
Reviewers: clayborg, zturner
Subscribers: mohit.bhakkad, sagar, jaydeep, lldb-commits
Differential Revision: http://reviews.llvm.org/D17022
llvm-svn: 261206
* Generate artificial symbol names from eh_fame during symbol parsing
so these symbols are already present when we calcualte the size of
the symbols where 0 is specified.
* Fix symbol size calculation for the last symbol in the file where
it have to last until the end of the parent section.
This is the re-commit of the original change after fixing some test
failures on OSX.
Differential revision: http://reviews.llvm.org/D16996
llvm-svn: 261205
This code was doing the right thing for the iOS simulator, but not other simulator platforms
Fix it by making the warning not happen for all platforms whose name ends in "-simulator"
Since this code lives in AppleObjCRuntimeV2.cpp, this already only applies to Apple platforms by definition, so I am not too worried about conflicts with other vendors
llvm-svn: 261165
This reverts commit 293c18e067d663e0fe93e6f3d800c2a4bfada2b0.
The BKPT instruction generates SIGBUS instead of SIGTRAP in the Linux
kernel on Nexus 6 - 5.1.1 (kernel version 3.10.40). Revert the CL
until we can figure out how can we hanble the SIGBUS or how to get
back a SIGTRAP using the BKPT instruction.
llvm-svn: 260969
The test fails very rarely. I suspect this is simply because the inferior does not have enough
time to create the file under heavy load.
llvm-svn: 260951
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
Aidan Dodds