summaryrefslogtreecommitdiffstats
path: root/lldb
Commit message (Collapse)AuthorAgeFilesLines
* Revive the error message from "process load" and SBProcess::LoadImage.Jim Ingham2016-06-081-1/+1
| | | | | | | | | | | IsPointedCString has problems with ValueObjects of type eTypeHostAddress. We should figure out the right thing to do in that case, but the test is silly here because we're reading a type we've defined, so we know it is a const char *, and if the memory is good, we won't be able to read any characters, when we do ReadPointedString. <rdar://problem/26612812> llvm-svn: 272087
* Now that there are no cycles that cause leaks in the ↵Greg Clayton2016-06-076-63/+9
| | | | | | | | disassembler/instruction classes, we can get rid of the FIXME lines that were working around this issue. <rdar://problem/26684190> llvm-svn: 272071
* Fix a memory leak in InstructionLLVMC where it held onto a strong reference ↵Greg Clayton2016-06-074-300/+394
| | | | | | | | | | | | | | | | | | | | | to the DisassemblerLLVMC which in turn had a vector of InstructionSP causing the strong cycle. This is fixed now. 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
* Revert "Make lldbinline.py regenerate the Makefile each time it builds."Pavel Labath2016-06-0710-91/+17
| | | | | | This reverts commit r272024 as it is not windows-compatible. llvm-svn: 272062
* Don't use SO_REUSEADDR for *client* socketsPavel Labath2016-06-071-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* LLDB is leaking memory in Editline.cpp on MacOSX. Greg Clayton2016-06-071-43/+62
| | | | | | | | | | | | 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
* Make lldbinline.py regenerate the Makefile each time it builds.Sean Callanan2016-06-0710-17/+91
| | | | | | | | | | | | | 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
* Add support for using armv7 compact unwind informationJason Molenda2016-06-074-56/+324
| | | | | | | | | | | | | | | 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
* Don't remove PIE executables when using svr4 packetsFrancis Ricci2016-06-061-4/+3
| | | | | | | | | | | | | | | 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
* (Minor tweak) Make RegisterContextWindows_x86/x64::GetRegisterInfoAtIndex Carlo Kok2016-06-062-2/+9
| | | | | | | | | | | | 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
* Fix function name lookup in IRExecutionEngine.cpp.Stephane Sezer2016-06-061-1/+1
| | | | | | | | | | | | | | 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
* Add armv7 compact unwind printing to the compact-unwind-dumper.c toolJason Molenda2016-06-041-0/+199
| | | | | | as a prototype for adding armv7 compact unwind reading to lldb. llvm-svn: 271774
* Fix a printf warning.Greg Clayton2016-06-031-2/+1
| | | | llvm-svn: 271716
* Add support in debug LLDB builds (if LLDB_CONFIGURATION_DEBUG is defined) ↵Greg Clayton2016-06-031-0/+40
| | | | | | | | | | where we can set an environment variable named LLDB_DWARF_DONT_COMPLETE_TYPENAMES that can contain one or more typenames separated by ';' characters. This will cause us to not complete any types whose names match and can help us to try and reproduce issues we see in bugs. So you can launch LLDB with the environment variable: % LLDB_DWARF_DONT_COMPLETE_TYPENAMES=Foo;Bar;Baz lldb llvm-svn: 271696
* Fix makefile for TestExternCSymbolsTamas Berghammer2016-06-031-1/+1
| | | | llvm-svn: 271618
* Fixed a problem where we couldn't call extern "C" functions.Sean Callanan2016-06-025-1/+79
| | | | | | | | | | | | | 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
* LLDB needs to be able to handle DW_AT_GNU_dwo_name that are relative to the ↵Greg Clayton2016-06-021-0/+16
| | | | | | | | DW_AT_comp_dir when using -gmodules with DWARF in .o files on darwin. <rdar://problem/26590227> llvm-svn: 271545
* Fixed a problem where -gmodules debug info would be loaded by the DWO file ↵Greg Clayton2016-06-021-0/+6
| | | | | | | | support accidentally and cause 1000s of files to be mapped into LLDB's address space for each .o file that reference a module. <rdar://problem/26580266> -gmodules causes LLDB.framework to map hundreds of copies of the same .pcm file llvm-svn: 271543
* Fix JavaArraySyntheticFrontEnd for non-reference ValueObject.Tamas Berghammer2016-06-021-1/+1
| | | | | | | | | | | | 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
* [tsan] Prefer mangled name looking up variable declaration for racy addressDevin Coughlin2016-06-014-1/+99
| | | | | | | | | | | | | | | | 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
* Add more verification on consectutive bitfields otherwise clang will assert.Greg Clayton2016-05-311-17/+35
| | | | | | | | 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
* [CMake] Update to requiring CMake 3.4.3Chris Bieneman2016-05-311-1/+1
| | | | | | | | | | | | | | Summary: This is as per the discussions on developer lists: http://lists.llvm.org/pipermail/llvm-dev/2016-April/098780.html http://lists.llvm.org/pipermail/llvm-dev/2016-May/100058.html Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20826 llvm-svn: 271328
* Implement ProcessInfo::Dump(), log gdb-remote stub launchTodd Fiala2016-05-314-9/+42
| | | | | | | | | | | | | | | | | | 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
* [LLDB] Make sure that indexing is done before clearing DIE infoCameron Desrochers2016-05-301-17/+68
| | | | | | | | | | | | | | | | "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
* fix up lldb-server platform on Apple hostsTodd Fiala2016-05-271-0/+3
| | | | | | | | | | | | 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
* Add a new "lldb" log channel named "demangle". If we have crashes that are ↵Greg Clayton2016-05-273-0/+27
| | | | | | | | related to demangling, we now can enable this logging and we will be able to reproduce demangler crashes (usually due to overflowing the stack) without needing someone's project. <rdar://problem/25221899> llvm-svn: 270941
* Lock the access to the BreakpointLocationCollection.Jim Ingham2016-05-262-2/+13
| | | | | | | | | | | | 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
* Don't cache the stret/vrs. non-stret code pointer as static data in the runtime.Jim Ingham2016-05-262-6/+6
| | | | | | | | | It belongs in the instance, since then when you change architectures it can be adjusted appropriately. <rdar://problem/26308079> llvm-svn: 270938
* With -gmodules, we have been having a harder time always finding a type when ↵Greg Clayton2016-05-261-2/+25
| | | | | | | | | | | | | | | | | | | | | | we need one. 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
* Make sure that we succeed in starting a definition before we complete it and ↵Greg Clayton2016-05-262-32/+80
| | | | | | | | | | | | | | | | emit an error if we fail to start the definition. 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
* Guard against the C++ destructor chain by not letting the debugger list ↵Greg Clayton2016-05-261-67/+49
| | | | | | | | | | clean up after itself in the C++ destructor chain. 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
* [cmake] Remove the LLDB versions of the exception-controlling variablesPavel Labath2016-05-261-22/+0
| | | | | | | | | | | | | | | 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
* [cmake] Add a big warning about a libstdc++ issuePavel Labath2016-05-261-0/+24
| | | | | | | | | | | | | | | | | | | | | | | 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
* Add "-gmodules" support to the test suite.Todd Fiala2016-05-2613-29/+108
| | | | | | | | | | | | | | 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
* [cmake] Add ability to customize (and skip) debugserver codesignPavel Labath2016-05-261-23/+25
| | | | | | | | | | | | | | | | | | 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
* Avoid using stdio in TestVirtualPavel Labath2016-05-262-20/+22
| | | | | | | | | | | | | | 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
* Small further refinement to the check in ObjectFileMachO::ParseSymtabJason Molenda2016-05-261-7/+9
| | | | | | | | | | | | | | | | | 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
* Make sure to try and take the process stop lock when calling:Greg Clayton2016-05-261-6/+11
| | | | | | | | | | | 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
* It has been brought to my attention that, given two variablesEnrico Granata2016-05-253-12/+17
| | | | | | | | | | | | | | | | | 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
* Mark some aarch64-linux specific xfails marking bug entriesOmair Javaid2016-05-253-2/+3
| | | | | | | | 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
* Add logging to ValueObjectSyntheticFilter such that one can trace through ↵Enrico Granata2016-05-251-8/+78
| | | | | | the creation of synthetic children llvm-svn: 270770
* Fix an issue where LLDB would crash if one tried to 'frame variable' an ↵Enrico Granata2016-05-252-4/+8
| | | | | | | | unordered_map more than once in a stop due to the synthetic provider not properly caching the ValueObjects it was returning for the child elements Fixes rdar://26470909 llvm-svn: 270752
* Mark some arm-linux specific xfails marking bug entriesOmair Javaid2016-05-254-1/+5
| | | | | | | | 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
* Add unit tests for ModuleCachePavel Labath2016-05-254-0/+192
| | | | | | | | | | Reviewers: ovyalov, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20570 llvm-svn: 270684
* Include <mutex> in Process.h - Jim's change in r270593 added a std::mutexJason Molenda2016-05-251-0/+1
| | | | | | | ivar and this header is needed for it to compile on linux, judging by the build bots. llvm-svn: 270662
* Add support for arm64 compact unwind tables, used on darwin arm64Jason Molenda2016-05-253-0/+340
| | | | | | | | | | | | | | 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
* Fix an issue where the NSDate data formatter was not using the proper ↵Enrico Granata2016-05-241-1/+3
| | | | | | | | alignment on watchOS targets Fixes rdar://problem/23298264 llvm-svn: 270621
* Ach, editing too many files at once. Make this file compile again.Jason Molenda2016-05-241-1/+1
| | | | llvm-svn: 270620
* In r268475 I made a change to ObjectFileMachO so that if it isJason Molenda2016-05-241-1/+4
| | | | | | | | | | | | | | | | 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
* Reword the "Happened at" TSan-reported thread to contain a thread id.Kuba Brecka2016-05-241-2/+5
| | | | llvm-svn: 270608
OpenPOWER on IntegriCloud