Rules are as follows for internal code using lldb::DisassemblerSP and lldb::InstructionSP:
1 - The disassembler needs to stay around as long as instructions do as the Instruction subclass now has a weak pointer to the disassembler
2 - The public API has been fixed so that if you get a SBInstruction, it will hold onto a strong reference to the disassembler in a new InstructionImpl class
This will keep code like like:
inst = lldb.target.ReadInstructions(frame.GetPCAddress(), 1).GetInstructionAtIndex(0)
inst.GetMnemonic()
Working as expected (not the SBInstructionList() that was returned by SBTarget.ReadInstructions() is gone, but "inst" has a strong reference inside of it to the disassembler and the instruction.
All code inside the LLDB shared library was verified to correctly hold onto the disassembler instance in all places.
<rdar://problem/24585496>
llvm-svn: 272069
Summary:
In the case of client sockets, we are not binding to a specific port, so we
should be able to just request a new one. Disregarding refactors, this code
has been here since the initial LLDB checkin, so I was unable to figure out
whether it was added as a fix for a specific problem, or just for symmetry
with server sockets, but I see no side-effect from removing it now. I was
still able to create 10000 connections within a couple of seconds, so I think
it's unlikely we will exhaust the port space (previously, I would get an
error after a couple thousand connections).
This fixes an occasional issue with connecting to the android debug bridge
deamon on OSX when running the test suite, which would occasionaly fail with
EADDRINUSE. My best guess is that this was happening because two processes
were assigned the same client port number, and then things blew up because
they were both trying to connect to the same ADB server port. I have not
observed this issue happening on Linux or Windows.
Reviewers: clayborg
Subscribers: tberghammer, danalbert, lldb-commits
Differential Revision: http://reviews.llvm.org/D21088
llvm-svn: 272041
When USE_SETUPTERM_WORKAROUND is enabled, we were calling setupterm() multiple times and leaking memory on each subsequent call. This is now fixed by calling setupterm() once in the constructor and tracking if we have already setup a terminal for a file descriptor.
Calls to "el_set (m_editline, EL_ADDFN, ..." were leaking memory. If we switch over to call el_wset with wide strings when LLDB_EDITLINE_USE_WCHAR is set, then we no longer leak memory each time we construct a new Editline object.
The calls to "el_set (m_editline, EL_ADDFN, ..." were changed over to call "el_wset (m_editline, EL_ADDFN, ...". Note that when LLDB_EDITLINE_USE_WCHAR is not defined, then el_wset is #define'ed to el_set. All strings are wrapped in EditLineConstString which will use wide strings when needed, and normal C strings when LLDB_EDITLINE_USE_WCHAR is not defined.
<rdar://problem/26677627>
llvm-svn: 272036
If a lldbinline test's source file changed language, then the Makefile wasn't
updated. This was a problem if the Makefile was checked into the repository.
Now lldbinline.py always regenerates the Makefile and asserts if the
newly-generated version is not the same as the one already there. This ensures
that the repository will never be out of date without a buildbot failing.
http://reviews.llvm.org/D21032
llvm-svn: 272024
as an asynchronous unwind plan source.
Two small fixes to the compact unwind dumper tool for
armv7 encodings.
A change to DWARFCallFrameInfo to strip the 0th bit on
addresses in eh_frame sections when armv7. In the
clang generated examples I have, the 0th bit is set for
thumb functions and that's causing the unwinder to pick
the wrong function for eh_frame info.
llvm-svn: 271970
Summary:
Because PIE executables have an e_type of llvm::ELF::ET_DYN,
they are not of type eTypeExecutable, and were being removed
when svr4 packets were used.
Reviewers: clayborg, ADodds, tfiala, sas
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20990
llvm-svn: 271899
return NULL for an invalid register.
The unwind logic asks for the "return address register" which doesn't exist
on x86/x86_64, returns -1 and calls this with -1 as a parameter, ends up
out of scope of the array bounds for g_register_infos and later SIGSEGVs
on accessing. This now matches the other GetRegisterInfoAtIndex for
other platforms.
llvm-svn: 271876
Summary:
Without this commit, when `log enable lldb expr` is enabled, the
disassembly of JIT'ed code is never displayed.
Reviewers: spyffe, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20312
llvm-svn: 271863
Some compilers do not mark up C++ functions as extern "C" in the DWARF, so LLDB
has to fall back (if it is about to give up finding a symbol) to using the base
name of the function.
This fix also ensures that we search by full name rather than "auto," which
could cause unrelated C++ names to be found. Finally, it adds a test case.
<rdar://problem/25094302>
llvm-svn: 271551
Summary: Fix missing return after checking that m_backend is not a pointer or reference type.
Reviewers: clayborg, tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20875
llvm-svn: 271453
For Thread Sanitizer reports, LLDB tries to find a global variable declaration
corresponding to the racy address in order to provide a filename and line
number. This commit changes the lookup of the variable to use the mangled
name for lookup and fall back to the demangled version if unavailable. This
is needed to report locations of races on Swift global variables.
I've also added a test to make sure we look up C++ globals correctly.
rdar://problem/26459401
Differential Revision: http://reviews.llvm.org/D20760
llvm-svn: 271433
We need to verify that consecutive bitfields have higher offsets and don't overlap. The issues was found by running a broken version of recent clangs where the bitfield offsets were being emitted incorrectly. To guard against this we now verify and toss out any invalid bitfields and print a message that indicates to file a bug against the compiler.
<rdar://problem/25737621>
llvm-svn: 271343
This change implements dumping the executable, triple,
args and environment when using ProcessInfo::Dump().
It also tweaks the way Args::Dump() works so that it prints
a configurable label rather than argv[{index}]={value}. By
default it behaves the same, but if the Dump() method with
the additional arg is provided, it can be overridden. The
environment variables dumped as part of ProcessInfo::Dump()
make use of that.
lldb-server has been modified to dump the gdb-remote stub's
ProcessInfo before launching if the "gdb-remote process" channel
is logged.
llvm-svn: 271312
"ClearDIEs()" was being called too soon, before everyone was done using the DIEs.
This fix delays the calls to ::ClearDIEs() until all compile units have been indexed.
1 - Call "::ExtractDIEsIfNeeded()" on all compile units on separate threads. See if each CU has the DIEs parsed and remember this.
2 - Index all compile units on separate threads.
3 - Clear any DIEs in any compile units that didn't have their DIEs parsed after all compile units have been indexed.
Patch by phlav
Differential Revision: http://reviews.llvm.org/D20738
llvm-svn: 271209
r259714 introduces the transport method into the
URL passed to the gdb-remote stub. On debugserver,
this is not supported and prevented debugserver from
being launched by lldb-server in platform mode.
This change skips the transport method addition from
r259714 when on Apple hosts.
llvm-svn: 270961
I was investigating an odd crash in lldb when the breakpoint site
goes to bump the hit counts of the locations it implements. I noticed
that the BreakpointLocationCollection wasn't locking itself for access and
modification. I don't see how that can cause the crash I'm seeing, but still
this is the right thing to do...
<rdar://problem/25178205>
llvm-svn: 270939
We have seen cases where we have been unable to find an argument type for a function, or we find one from another language, and then we try to create a function type by calling:
lldb_private::ClangASTContext::CreateFunctionType(clang::ASTContext*, lldb_private::CompilerType const&, lldb_private::CompilerType const*, unsigned int, bool, unsigned int)
This fix will ensure that all arguments to lldb_private::ClangASTContext::CreateFunctionType() are in order by checking:
- AST is valid
- if arguments are specified we have a valid argument array
- return type is valid
- return type is a clang type
- all argument types are valid
- all argument types are clang types
If any of these fail, we return an invalid CompilerType. If we don't return an invalid type, clang will crash anyway, and LLDB must not crash even in the presence of bad or missing debug info.
<rdar://problem/25172715>
llvm-svn: 270932
ClangASTContext::StartTagDeclarationDefinition(...) was starting definitions for any TagType instances that have TagDecl, but ClangASTContext::CompleteTagDeclarationDefinition(...) was getting the type to a CXXRecordDecl with:
clang::CXXRecordDecl *cxx_record_decl = qual_type->getAsCXXRecordDecl();
The problem is that getAsCXXRecordDecl() might dig a bit deeper into a type and dig out a different decl, which means we might call ClangASTContext::StartTagDeclarationDefinition(...), but it might not do anything, and then we might call ClangASTContext::CompleteTagDeclarationDefinition(...) and it might try to complete something that didn't have its definition started and this will crash.
This change fixes that, and also makes sure that starting a definition succeeds before any calls to ClangASTContext::CompleteTagDeclarationDefinition().
<rdar://problem/24091798>
llvm-svn: 270891
If users call "static void lldb::SBDebugger::Terminate()" we will clean up the debugger list, and users can individually destroy debugger instances with "static void lldb::SBDebugger::Destroy(SBDebugger &)". But if we let the C++ destructor chain tear down this list, other threads that might still be running as the main thread exits can now crash if they access the debugger list. We stop this by leaking the debugger list and its mutex.
<rdar://problem/26372169>
llvm-svn: 270869
Summary:
One can still use the LLVM variables to control this: LLVM_ENABLE_EH, LLVM_ENABLE_RTTI. It's not
clear to me why one would want to control these at lldb level and it's generally not even a good
idea to compile parts of the same binary with different values of these flags.
Reviewers: zturner, tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20673
llvm-svn: 270863
Summary:
Recent increase in the usage of std::weak_ptr has caused us to rediscover an issue in libstdc++
versions prior to 4.9 <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59656>, which make this class
unusable without exceptions in the presence of multiple threads. It's virtualy impossible to work
around this issue without implementing our own shared_ptr/weak_ptr substitutes, which does not
seem like a good idea.
Therefore, I am adding a big CMake warning which warns you about this issue if you're attempting
a to do a build which is suceptible to this problem and suggests possible alternatives. Right
now, nothing spectacular will happen if you ignore this warning (all the crashes I have seen
occur during process shutdown), but there's no guarantee the situation will not change in the
future.
Reviewers: tberghammer, tfiala, nitesh.jain, omjavaid, emaste, krytarowski
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20671
llvm-svn: 270854
This change adds the capability of building test inferiors
with the -gmodules flag to enable module debug info support.
Windows is excluded per @zturner.
Reviewers: granata.enrico, aprantl, zturner, labath
Subscribers: zturner, labath, lldb-commits
Differential Revision: http://reviews.llvm.org/D19998
llvm-svn: 270848
Summary:
This adds the ability to customize the debugserver codesign process via cmake cache variable. The
user can set the codesign indentity (with the default being the customary lldb_codesign), and if
the identity is set to a empty string, the codesign step is skipped completely.
We needed the last feature to enable building lldb on buildservers which do not have the right
certificates installed.
Reviewers: sas, tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20623
llvm-svn: 270832
Summary:
using stdio in tests does not work on windows, and it is not completely reliable on linux.
Avoid using stdio in this test, as it is not necessary for this purpose.
Reviewers: clayborg
Subscribers: lldb-commits, zturner
Differential Revision: http://reviews.llvm.org/D20567
llvm-svn: 270831
which looks for binaries missing an LC_FUNCTION_STARTS section because
it was stripped/not emitted. If we see a normal user process binary
(executable, dylib, framework, bundle) without LC_FUNCTION_STARTS, that
is unusual and we should disallow instruction emulation because that
binary has likely been stripped a lot.
If this is a non-user process binary -- a kernel, a standalone bare-board
binary, a kernel extension (kext) -- and there is no LC_FUNCTION_STARTS,
we should not assume anything about the binary and allow instruction
emulation as we would normally do.
<rdar://problem/26453952>
llvm-svn: 270818
uint32_t SBProcess::GetNumQueues();
SBQueue SBProcess::GetQueueAtIndex (size_t index);
Otherwise this code will run when the process is running and cause problems.
<rdar://problem/26482744>
llvm-svn: 270803
T x;
U y;
doing
x = *((T*)y)
is undefined behavior, even if sizeof(T) == sizeof(U), due to pointer aliasing rules
Fix up a couple of places in LLDB that were doing this, and transform them into a defined and safe memcpy() operation
Also, add a test case to ensure we didn't regress by doing this w.r.t. tagged pointer NSDate instances
llvm-svn: 270793
TestBSDArchives.py and TestWatchLocation.py fail due to unicode error and bug has already been reported for arm and macOSx.
TestConstVariables.py fails because lldb cant figure out frame variable type when used in expr.
llvm-svn: 270780
TestCallUserAnonTypedef.py and TestIRInterpreter.py fail to limitation of JIT expressions in handling hard float ABI targets.
TestBSDArchives.py fails due to python unicode error.
TestBuiltinTrap.py fails due to wrong line information generated by some gcc versions.
llvm-svn: 270745
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
Both of above tests fail on arm and bugs have been reported on android already.
Adding arm-linux decorator because android decorator doesnt xfail these test when run on linux.
llvm-svn: 269647
NPL now assumes it is running from a single thread now, so its thread-safety is untested
anyway (and if that assumption is broken, we'll have bigger problems (due to ptrace restrictions)
than a couple of missing mutexes).
llvm-svn: 269640
The variables referenced in the print message are not defined. Simply state
that the requisite script is not found. Correct grammar to indicate that the
tests are rather likely to fail rather than unlikely to fail.
llvm-svn: 269628
The parameter here is a list, not a string. Ensure that the we splat the list
into arguments prior to invoke os.path.join. This would previously fail with a
`startswith` is not a member of `list`.
llvm-svn: 269627
Greg Clayton