summaryrefslogtreecommitdiffstats
path: root/lldb
Commit message (Collapse)AuthorAgeFilesLines
...
* When support for DWO files was added, there were two ways to pass ↵Greg Clayton2016-03-3018-333/+360
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | lldb::user_id_t out to the rest of LLDB: 1 - DWARF in .o files with debug map in executable: we would place the compile unit index in the upper 32 bits of the 64 bit value and the lower 32 bits would be the DIE offset 2 - DWO: we would place the compile unit offset in the upper 32 bits of the 64 bit value and the lower 32 bits would be the DIE offset There was a mixing and matching of this and it wasn't done consistently. Major changes include: The DIERef constructor that takes a lldb::user_id_t now requires a SymbolFileDWARF: DIERef(lldb::user_id_t uid, SymbolFileDWARF *dwarf) It is needed so that it can be decoded correctly. If it is DWARF in .o files with debug map in executable, then we get the right compile unit from the SymbolFileDWARFDebugMap, otherwise, we use the compile unit offset and DIE offset for DWO or normal DWARF. The function: lldb::user_id_t DIERef::GetUID() const; Now becomes lldb::user_id_t DIERef::GetUID(SymbolFileDWARF *dwarf) const; Again, we need the DWARF file to encode it correctly. This removes the need for "lldb::user_id_t SymbolFileDWARF::MakeUserID() const" and for bool SymbolFileDWARF::UserIDMatches (lldb::user_id_t uid) const". There were also many places were doing things inneficiently like: 1 - encode a dw_offset_t into a lldb::user_id_t 2 - call the public SymbolFile interface to resolve types using the lldb::user_id_t 3 - This would then decode the lldb::user_id_t into a DIERef, and then try to find that type. There are many places that are now doing this more efficiently by storing DW_AT_type form values as DWARFFormValue objects and then making a DIERef from them and directly calling the underlying function to resolve the lldb_private::Type, lldb_private::CompilerType, lldb_private::CompilerDecl, lldb_private::CompilerDeclContext. If there are any regressions in DWARF with DWO, we will need to fix any issues that arise since the original patch wasn't functional for the much more widely used DWARF in .o files with debug map. <rdar://problem/25200976> llvm-svn: 264909
* Fix header name.Jim Ingham2016-03-301-1/+1
| | | | llvm-svn: 264883
* Fix the ThreadSanitizer support to avoid creating empty SBThreads and to not ↵Kuba Brecka2016-03-302-2/+6
| | | | | | crash when thread_id is unavailable. Plus a whitespace fix. llvm-svn: 264854
* Fix SocketAddressTest (again)Pavel Labath2016-03-301-1/+2
| | | | | | | On some versions of Windows, the address is returned as "::1", while on others it's "0:0:...:0:1". Accept both versions, as they represent the same address. llvm-svn: 264850
* Fix warning in ThreadSanitizerRuntimePavel Labath2016-03-301-1/+1
| | | | llvm-svn: 264849
* Fix warning in ClangExpressionParserPavel Labath2016-03-301-1/+1
| | | | llvm-svn: 264847
* Fix flakyness in TestWatchpointMultipleThreadsPavel Labath2016-03-302-13/+3
| | | | | | | | | | | | | | | | | | | | | | Summary: the inferior in the test deliberately does not lock a mutex when accessing the watched variable. The reason for that is unclear as, based on the logs, the original intention of the test was to check whether watchpoints get propagated to newly created threads, which should work fine even with a mutex. Furthermore, in the unlikely event (which I have still observed happening from time to time) that two threads do manage the execute the "critical section" simultaneously, the test will fail, as it is expecting the watchpoint "hit count" to be 1, but in this case it will be 2. Given this, I have simply chose to lock the mutex always, so that we have more predictible behavior. Watchpoints being hit simultaneously is still (and correctly!) tested by TestConcurrentEvents. Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18558 llvm-svn: 264846
* Don't register the addresses of private symbols from expressions.Sean Callanan2016-03-301-1/+1
| | | | | | | | 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
* Fixed the failing test TestCommandScriptImmediateOutput on MacOSX. Turns out ↵Greg Clayton2016-03-303-6/+6
| | | | | | | | | | | | | | | | | | | | | that there are few things to watch out for when writing pexpect tests: 1 - If you plan on looking for the "(lldb) " prompt as a regular expression, look for "\(lldb\) " so you don't just find "lldb". 2 - Make sure to not use colors (specify --no-use-colors as an option to lldb when launching it) as our editline will print: "(lldb) <color junk>(lldb) " where "<color junk>" is a work around that is used to allow us to colorize our prompts. The bad thing is this will make pexepct code like this not execute as you would expect: prompt = "\(lldb\) " self.child.sendline("breakpoint set ...", prompt) self.child.sendline("breakpoint clear ...", prompt) The problem is the first "sendline" will create two lldb prompts and will match both the first and second prompts and you output will get off. So be sure to disable colors if you need to. Fixed a case where "TestCommandScriptImmediateOutput.py" would fail if you have spaces in your directory names. I modified custom_command.py to use shlex to parse arguments and I quoted the file path we sent down to the custom_command.write_file function. llvm-svn: 264810
* LLDB top of tree SVN fails to attach to a MacOSX native process by pid only ↵Greg Clayton2016-03-291-2/+2
| | | | | | | | | | (no executable). The problem was that the static DynamicLoaderDarwinKernel::Initialize() was recently changed to come before DynamicLoaderMacOSXDYLD::Initialize() which caused the DynamicLoaderDarwinKernel::CreateInstance(...) to be called before DynamicLoaderMacOSXDYLD::CreateInstance(...) and DynamicLoaderDarwinKernel would claim it could be the dynamic loader for a user space MacOSX process. The fix is to make DynamicLoaderDarwinKernel::CreateInstance() a bit more thourough when vetting the process so that it doesn't claim MacOSX user space processes. <rdar://problem/25425373> llvm-svn: 264794
* Figure out what the fixed expression is, and print it. Added another target ↵Jim Ingham2016-03-2913-68/+217
| | | | | | | | | | | | | setting to 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
* When creating typedefs, don't call Type::GetName() since that might ↵Greg Clayton2016-03-291-4/+4
| | | | | | | | recursively call "lldb_private::Type::ResolveClangType(lldb_private::Type::ResolveStateTag)" and cause a crash. A lldb_private::Type should have a valid name if it is created without a backing CompilerType. Also provide a name that we can recognize so if we see it in a as the typename of a variable, we will know to check it out. This crash is happening quite a bit and we need to determine if this is due to incorrect debug info, or just due to some bug in LLDBD. <rdar://problem/25192037> llvm-svn: 264762
* Don't try to call getTypeSize() on a class if it isn't complete as clang ↵Greg Clayton2016-03-291-1/+9
| | | | | | will assert and kill the process. llvm-svn: 264753
* Move DynamicLoader plugins to SystemInitializerFullPavel Labath2016-03-292-12/+12
| | | | | | | | | | | | Summary: These are not needed by lldb-server. Removing them shrinks the server by about 0.5%. Reviewers: zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18206 llvm-svn: 264735
* Revert the "build fix" in r264104Pavel Labath2016-03-291-4/+0
| | | | | | | | this was needed because lldb-mi temporarily contained references to private lldb symbols (lldb_private namespace), which it shouldn't have. The situation has since been rectified and this wasn't the right fix anyway, since it can lead to funny ODR violations. llvm-svn: 264733
* Fix infinite recursion in DWO file parsingPavel Labath2016-03-294-37/+45
| | | | | | | | | | | | | | | | | | Summary: Since r264316, clang started adding DW_AT_GNU_dwo_name attribute to dwo files (previously, this attribute was only present in main object files), breaking pretty much every dwo test. The problem was that we were treating the presence of said attribute as a signal that we should look for information in an external object file, and caused us to enter an infinite loop. I fix this by making sure we do not go looking for an external dwo file if we already *are* parsing a dwo file. Reviewers: tberghammer, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18547 llvm-svn: 264729
* Add ClangUtil.cpp to the xcode projectPavel Labath2016-03-291-0/+8
| | | | llvm-svn: 264721
* Add missing swig wrappers for r264662Pavel Labath2016-03-291-0/+5
| | | | llvm-svn: 264713
* Move some functions from DWARFASTParserClang to ClangASTImporter.Zachary Turner2016-03-2817-611/+584
| | | | | | | | | | | | | | | | | | This allows these functions to be re-used by a forthcoming PDBASTParser. The functions in question are CanCompleteType, CompleteType, and CanImport. Conceptually, these functions belong on ClangASTImporter anyway, and previously they were just ping ponging around through a few levels of indirection to end up there as well, so this patch actually makes the code somewhat simpler. A few methods were moved to a new file called ClangUtil, so that they can be shared between ClangASTImporter and ClangASTContext without creating a circular dependency between those two cpp files. Differential Revision: http://reviews.llvm.org/D18381 llvm-svn: 264685
* Expose top-level Clang expressions via the command line and the API.Sean Callanan2016-03-2810-1/+206
| | | | | | | | | | | | | | | | | | Top-level Clang expressions are expressions that act as new translation units, and define their own symbols. They do not have function wrappers like regular expressions do, and declarations are persistent regardless of use of the dollar sign in identifiers. Names defined by these are given priority over all other symbol lookups. This patch adds a new expression option, '-p' or '--top-level,' which controls whether the expression is treated this way. It also adds a flag controlling this to SBExpressionOptions so that this API is usable externally. It also adds a test that validates that this works. (The test requires a fix to the Clang AST importer which I will be committing shortly.) <rdar://problem/22864976> llvm-svn: 264662
* Don't try to actually run code when the expression is top-level.Sean Callanan2016-03-281-0/+5
| | | | llvm-svn: 264660
* Removed an override of LookupSymbol that mistakenly disabled it for Clang.Sean Callanan2016-03-281-3/+0
| | | | llvm-svn: 264659
* When we import the definition for a Tagdecl, propagate its completeness too.Sean Callanan2016-03-261-3/+14
| | | | | | | | | | | The ASTImporter completes the full definiton for a TagDecl in several places, including the type-deport logic. When this happens, we should also propagate the bit that says that this is a complete definition. This makes (for example) lambdas callable. <rdar://problem/22864976> llvm-svn: 264485
* Record all translation units with more than one function in them (e.g., blocks).Sean Callanan2016-03-261-3/+9
| | | | | | | | | | | Blocks and lambdas have their implementation functions stored in the IR for an expression. If we put the block/lambda into a result variable it needs to stay around. As a heuristic, remember any execution unit that has more than one function in it. <rdar://problem/22864976> llvm-svn: 264483
* Removed LoggingDiagnosticConsumer, an unused class.Sean Callanan2016-03-251-50/+0
| | | | llvm-svn: 264478
* Fix FILE * leak in Python APIStephane Sezer2016-03-253-9/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This fixes a leak introduced by some of these changes: r257644 r250530 r250525 The changes made in these patches result in leaking the FILE* passed to SetImmediateOutputFile. GetStream() will dup() the fd held by the python caller and create a new FILE*. It will then pass this FILE* to SetImmediateOutputFile, which always uses the flag transfer_ownership=false when it creates a File from the FILE*. Since transfer_ownership is false, the lldb File destructor will not close the underlying FILE*. Because this FILE* came from a dup-ed fd, it will also not be closed when the python caller closes its file. Leaking the FILE* causes issues if the same file is used multiple times by different python callers during the same lldb run, even if these callers open and close the python file properly, as you can end up with issues due to multiple buffered writes to the same file. Reviewers: granata.enrico, zturner, clayborg Subscribers: zturner, lldb-commits, sas Differential Revision: http://reviews.llvm.org/D18459 Change by Francis Ricci <fjricci@fb.com> llvm-svn: 264476
* Add a 'language cplusplus demangle' command. This can be useful to provide a ↵Enrico Granata2016-03-251-1/+89
| | | | | | low-friction reproduction for issues with the LLDB demangling of C++ symbols llvm-svn: 264474
* Fix an issue with nested aliases where the help system wouldn't correctly ↵Enrico Granata2016-03-253-0/+23
| | | | | | | | track the fact that an alias is an alias to a dash-dash alias (and I hope I typed the word 'alias' enough times in this commit message :-) llvm-svn: 264468
* Fix now-ambiguous references to Error.Lang Hames2016-03-251-5/+5
| | | | llvm-svn: 264449
* Add the same host logging that I added to PlatformRemoteiOS a fewJason Molenda2016-03-252-1/+154
| | | | | | | | months back to PlatformRemoteAppleTV and PlatformRemoteAppleWatch to help understand what's happening when lldb can't find binaries that it should be finding. llvm-svn: 264380
* Use Clang's FixItHints to correct expressions with "trivial" mistakes (e.g. ↵Jim Ingham2016-03-2519-29/+562
| | | | | | | | | | | | | | | "." for "->".) 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
* Ignore global constructor warning in clang.Greg Clayton2016-03-241-0/+4
| | | | llvm-svn: 264361
* Make it possible for language plugins to provide additional custom help for ↵Enrico Granata2016-03-243-2/+37
| | | | | | 'type lookup' llvm-svn: 264356
* Update the INFOPLIST_FILE setting in the xcode project fileJason Molenda2016-03-242-5/+5
| | | | | | | | so that the lldb command line binary's version #'s are updated correctly. <rdar://problem/25346711> llvm-svn: 264353
* Make File option flags consistent for Python APIStephane Sezer2016-03-243-3/+46
| | | | | | | | | | | | | | | | | | Summary: Fixes SBCommandReturnObject::SetImmediateOutputFile() and SBCommandReturnObject::SetImmediateOutputFile() for files opened with "a" or "a+" by resolving inconsistencies between File and our Python parsing of file objects. Reviewers: granata.enrico, Eugene.Zelenko, jingham, clayborg Subscribers: lldb-commits, sas Differential Revision: http://reviews.llvm.org/D18228 Change by Francis Ricci <fjricci@fb.com> llvm-svn: 264351
* Get rid of a global constructor and also make this code safe to use after ↵Greg Clayton2016-03-241-14/+30
| | | | | | the global destructor chain has been run on the main thread. llvm-svn: 264348
* Get rid of two global constructors by making things static variables in the ↵Greg Clayton2016-03-242-9/+8
| | | | | | only function that uses these variables. llvm-svn: 264347
* Get rid of a global constructor that was causing a warning on MacOSX and ↵Greg Clayton2016-03-242-4/+14
| | | | | | make the Timer safe to use after the main threads global destructor chain is called. llvm-svn: 264346
* Make 'type lookup' print an error message instead of complete radio silence ↵Enrico Granata2016-03-242-0/+4
| | | | | | | | when it can't find a type matching user input It would be fun to make it provide suggestions (e.g. 'can't find NString, did you mean NSString instead?'), but this worries me a little bit on the account of just how thorough of a type system scan it would have to do llvm-svn: 264343
* Fix for missing prompt on WindowsTed Woodward2016-03-241-0/+23
| | | | | | | | | | | | Summary: On Windows (and possibly other hosts with LLDB_DISABLE_LIBEDIT defined), the (lldb) prompt won't print after async output, like from a breakpoint hit or a step. This patch forces the prompt to be printed out after async output. Reviewers: zturner, clayborg Subscribers: amccarth, lldb-commits Differential Revision: http://reviews.llvm.org/D18335 llvm-svn: 264332
* [JITLoaderGDB] Read jit entry struct manually.Siva Chandra2016-03-232-51/+63
| | | | | | | | | | | | | | | | Summary: Though r264012 was fancy enough to make reading the jit entry struct work with templates, the packing and alignment attributes do not work on Windows. So, this change makes it plain and simple with manual reading of the jit entry struct. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18379 llvm-svn: 264217
* Implement ObjectFilePECOFF::GetEntryPointAddress.Stephane Sezer2016-03-232-3/+24
| | | | | | | | | | Reviewers: zturner, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17970 llvm-svn: 264173
* Follow-up for r264162 to fix the CMake build (update LLDBDependencies.cmake).Kuba Brecka2016-03-231-0/+1
| | | | llvm-svn: 264168
* Add ThreadSanitizer debugging support.Kuba Brecka2016-03-2317-1/+954
| | | | | | | | | | | | This patch adds ThreadSanitizer support into LLDB: - Adding a new InstrumentationRuntime plugin, ThreadSanitizerRuntime, in the same way ASan is implemented. - A breakpoint stops in `__tsan_on_report`, then we extract all sorts of information by evaluating an expression. We then populate this into StopReasonExtendedInfo. - SBThread gets a new API, SBThread::GetStopReasonExtendedBacktraces(), which returns TSan’s backtraces in the form of regular SBThreads. Non-TSan stop reasons return an empty collection. - Added some test cases. Reviewed by Greg Clayton. llvm-svn: 264162
* Change 'apropos' such that it doesn't look into the "long help/syntax" ↵Enrico Granata2016-03-237-79/+82
| | | | | | | | | | strings for commands This solves issues such as 'apropos foo' returning valid matches just because syntax examples happen to use 'foo' as a placeholder token Fixes rdar://9043025 llvm-svn: 264123
* Reverted a change in r264074 that made lldb-mi use lldb_private APIs.Sean Callanan2016-03-221-1/+2
| | | | | | | | FileSystem::Fopen is a lldb_private API, but lldb-mi uses only the public API. Depending on lldb_private APIs makes Xcode builds fail. I reverted the portion of r264074 that added such a dependency. llvm-svn: 264113
* Make it so that a command alias can actually remove the help/long help from ↵Enrico Granata2016-03-226-48/+67
| | | | | | its parent command by setting itself to an empty help string llvm-svn: 264108
* [lldb-mi] Uncomment a line in CMakeLists.txt to make linux build happy.Siva Chandra2016-03-221-1/+1
| | | | | | | | | | Reviewers: zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18377 llvm-svn: 264104
* Fix a bug caused by my alias refactoring where, if an alias was defined in ↵Enrico Granata2016-03-226-2/+116
| | | | | | terms of another alias, trying to run the nested command would actually cause a crash in the command interpreter llvm-svn: 264096
* Backend support for top-level Clang epxressionsSean Callanan2016-03-229-212/+375
| | | | | | | | | | | | | | | | | | This patch adds a new ExecutionPolicy, eExecutionPolicyTopLevel, which tells the expression parser that the expression should be JITted as top level code but nothing (except static initializers) should be run. I have modified the Clang expression parser to recognize this execution policy. On top of the existing patches that support storing IR and maintaining a map of arbitrary Decls, this is mainly just patching up a few places in the expression parser. I intend to submit a patch for review that exposes this functionality through the "expression" command and through the SB API. That patch also includes a testcase for all of this. <rdar://problem/22864976> llvm-svn: 264095
OpenPOWER on IntegriCloud