systems (ios, tvos, watchos). It's a simple format to use now that
I have i386/x86_64 supported already.
The unwind instructions are only valid at call sites -- that is,
when lldb is unwinding a frame in the middle of the stack. It
cannot be used for the currently executing frame; it has no information
about prologues/epilogues/etc.
<rdar://problem/12062336>
llvm-svn: 270658
missing an LC_FUNCTION_STARTS section, we assume it has been
aggressively stripped (it is *very* unusual for anyone to strip
LC_FUNCTION_STARTS) so we disable assembly instruction unwind plan
creation.
Kernel extensions (kexts) don't have LC_FUNCTION_STARTS, but we
almost always have good symbol bounds just with the linker symbols.
So add an exception to allow assembly instruction unwind plan
creation for kexts even though they lack LC_FUNCTION_STARTS.
<rdar://problem/26453952>
llvm-svn: 270618
What with all sorts of folks (TSAN, ASAN, queue detection, etc...) trying to
gather info by calling functions down in the lower layers of lldb, we've started
to see people running expressions simultaneously. The expression evaluation part
is okay, but only one RunThreadPlan can be active at a time. I added a lock to
enforce that.
<rdar://problem/26431072>
llvm-svn: 270593
Summary:
The StringExtractor functions using stroull will already
skip leading whitespace (ie GetU64). Make sure that the manual
hex parsing functions also skip leading whitespace.
This is important for members of the gdb protocol which are defined
as using whitespace separators (ie qfThreadInfo, qC, etc). While
lldb-server does not use the whitespace separators, gdb-remotes
should work if they do, as the whitespace is defined by the gdb-remote
protocol.
Reviewers: vharron, jasonmolenda, clayborg
Subscribers: sas, lldb-commits
Differential Revision: http://reviews.llvm.org/D20509
llvm-svn: 270592
some (I'm not sure why only some, actually) implementations of std::map require the value type to
be a fully specified type when declaring then. This make sure TypeAndOrName is.
llvm-svn: 270570
Patch by Nitesh Jain.
Summary: These patch fix thread step-out for hard and soft float.
Reviewers: jaydeep, bhushan, clayborg
Differential Revision: http://reviews.llvm.org/D20416
llvm-svn: 270564
One of the things slowing us down is that ItaniumABILanguageRuntime class doesn't cache vtable to types in a map. This causes us, on every step, for every variable, to read the first pointer in a C++ type that could be dynamic and lookup the symbol, possibly in every symbol file (some symbols files on Darwin can end up having thousands of .o files when using DWARF in .o files, so thousands of .o files are searched each time).
This fix caches lldb_private::Address (the resolved vtable symbol address in section + offset format) to TypeAndOrName instances inside the one ItaniumABILanguageRuntime in a process. This allows caching of dynamic types and stops us from always doing deep searches in each file.
<rdar://problem/18890778>
llvm-svn: 270488
m_decl_objects is problematic because it assumes that each VarDecl has a unique
variable associated with it. This is not the case in inline contexts.
Also the information in this map can be reconstructed very easily without
maintaining the map. The rest of the testsuite passes with this cange, and I've
added a testcase covering the inline contexts affected by this.
<rdar://problem/26278502>
llvm-svn: 270474
There is flakiness somewhere in the core infrastructure on Windows,
so to get the buildbot reliably green we need to mark all tests
as flaky.
llvm-svn: 270460
On Darwin if a mmap file is code signed and the code signature is invalid, it used to crash. If we specify the MAP_RESILIENT_CODESIGN mmap flag when mapping a file for reading, we can avoid crashing.
Another mmap flag named MAP_RESILIENT_MEDIA allows us to survive if we mmap files that are on removable media like network servers or removable hard drives. If a file was mapped and later the media that had the file became unavailable, we would crash when we would touch the next page that wasn't paged in. Now it will return zeroes and stop of from us from crashing.
<rdar://problem/25918698>
llvm-svn: 270254
The CL causes a build breakage on platforms where sizeof(double) == sizeof(long double)
and it incorrectly assumes that sizeof(double) and sizeof(long double) is the same
on the host and the target.
llvm-svn: 270214
Patch by Nitesh Jain.
Summary: Currently floating point regsiters has eEncodingUint encoding. Hence register write '1.25' will failed. This patch add eEncodingIEEE754 encoding for floating point registers( - ). This patch will fix test_fp_register_write in TestRegisters.py
Reviewers: clayborg, sagar
Subscribers: mohit.bhakkad, jaydeep, bhushan, sdardis, lldb-commits
Differential: D18853
llvm-svn: 270208
In the android-arm ndk there is a duplicated typedef in link.h
and in unwind.h causing build erros. This CL introduces a HACK
to prevent LLVM from finding unwind.h to fix the issue.
llvm-svn: 270201
values for the pc or return address register.
On ios with arm64 and a binary that has multiple functions without
individual symbol boundaries, we end up with an assembly profile
unwind plan that says lr=<same> - that is, the link register contents
are unmodified from the caller's value. This gets the unwinder in
a loop.
When we're off the 0th frame, we never want to look to a caller for
a pc or return-address register value.
Add checks to ReadGPRValue and ReadRegister to prevent both the pc
and ra register values from recursing.
If this causes problems with backtraces on android, let me know or
back it out and I'll look into it -- but I think these are
straightforward and don't expect problems.
<rdar://problem/24610365>
llvm-svn: 270162
Summary: One of the cases handled by ValueObjectChild::UpdateValue() uses the entire width of the parent's scalar value as the size of the child, and extracts the child by calling Scalar::ExtractBitfield(). This seems valid but APInt::trunc(), APInt::sext() and APInt::zext() assert that the bit field must not have the same size as the parent scalar. Replacing those calls with sextOrTrunc(), zextOrTrunc(), sextOrSelf() and zextOrSelf() fixes the assertion failures.
Reviewers: uweigand, labath
Subscribers: labath, lldb-commits
Differential Revision: http://reviews.llvm.org/D20355
llvm-svn: 270062
The error was not getting propagated to the caller, so the higher layers thought the breakpoint
was successfully set & resolved.
I added a testcase, but it assumes 0x0 is not a valid place to set a breakpoint. On most systems
that is true, but if it isn't true of your system, either find another good place and add it to the
test, or x-fail the test.
<rdar://problem/26345962>
llvm-svn: 270014
The __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED macro is only defined on OS X, so the check as written compiled the code out for iOS
The right thing to do is compile the code out for older OSX versions, but leave iOS alone
rdar://26333564
llvm-svn: 270004
TestTopLevelExprs fails on arm and aarch64 linux similar to behaviour on android.
A bug exists here: llvm.org/pr27787.
This patch marks xfail on arm and aarch64.
llvm-svn: 269980
This is a pretty straightforward first pass over removing a number of uses of
Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there
are interfaces which take Mutex::Locker & to lock internal locks. This patch
cleans up most of the easy cases. The only non-trivial change is in
CommandObjectTarget.cpp where a Mutex::Locker was split into two.
llvm-svn: 269877
TestWatchLocation.py fails on arm-linux target due to unicode error in lldb testsuite.
This is a known issue and same test fails on OS X with similar reason.
I have reported a bug and marked this test as xfail for arm-linux targets.
llvm-svn: 269860
On OS X systems, look for /Applications/CMake.app and ~/Applications/CMake.app
versions of the cmake command line binary when trying harder to find a cmake not
on the system path.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20303
llvm-svn: 269713
Pavel Labath