summaryrefslogtreecommitdiffstats
path: root/lldb/source/Commands
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix more functions in Args to use StringRef.Zachary Turner2016-09-1911-32/+50
| | | | | | | | | | | | | | | This patch also marks the const char* versions as =delete to prevent their use. This has the potential to cause build breakages on some platforms which I can't compile. I have tested on Windows, Linux, and OSX. Best practices for fixing broken callsites are outlined in Args.h in a comment above the deleted function declarations. Eventually we can remove these =delete declarations, but for now they are important to make sure that all implicit conversions from const char * are manually audited to make sure that they do not invoke a conversion from nullptr. llvm-svn: 281919
* Convert many functions to use StringRefs.Zachary Turner2016-09-171-4/+7
| | | | | | | | | | | | | Where possible, remove the const char* version. To keep the risk and impact here minimal, I've only done the simplest functions. In the process, I found a few opportunities for adding some unit tests, so I added those as well. Tested on Windows, Linux, and OSX. llvm-svn: 281799
* Add SB API's for writing breakpoints to & creating the from a file.Jim Ingham2016-09-141-110/+17
| | | | | | | | | | | Moved the guts of the code from CommandObjectBreakpoint to Target (should have done it that way in the first place.) Added an SBBreakpointList class so there's a way to specify which breakpoints to serialize and to report the deserialized breakpoints. <rdar://problem/12611863> llvm-svn: 281520
* Some more pointer safety in Breakpoint.Zachary Turner2016-09-132-9/+10
| | | | | | | | | | | Plumb unique_ptrs<> all the way through the baton interface. NFC, this is a minor improvement to remove the possibility of an accidental pointer ownership issue. Reviewed By: jingham Differential Revision: https://reviews.llvm.org/D24495 llvm-svn: 281360
* This is the main part of a change to add breakpoint save and restore to lldb.Jim Ingham2016-09-122-76/+339
| | | | | | | | | | | | | | | Still to come: 1) SB API's 2) Testcases 3) Loose ends: a) serialize Thread options b) serialize Exception resolvers 4) "break list --file" should list breakpoints contained in a file and "break read -f 1 3 5" should then read in only those breakpoints. <rdar://problem/12611863> llvm-svn: 281273
* I'm experimenting with changing how the mixed source & assemblyJason Molenda2016-09-081-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-0658-28378/+24670
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* Fixing an MSVC error from rL280692Dimitar Vlahovski2016-09-061-1/+1
| | | | | | | | | MSVC emits an error when one uses a const variable in a lambda without capturing it. gcc and clang don't emit an error in this scenario. llvm-svn: 280707
* Added the "frame diagnose" command and use its output to make crash info better.Sean Callanan2016-09-061-0/+203
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When a process stops due to a crash, we get the crashing instruction and the crashing memory location (if there is one). From the user's perspective it is often unclear what the reason for the crash is in a symbolic sense. To address this, I have added new fuctionality to StackFrame to parse the disassembly and reconstruct the sequence of dereferneces and offsets that were applied to a known variable (or fuction retrn value) to obtain the invalid pointer. This makes use of enhancements in the disassembler, as well as new information provided by the DWARF expression infrastructure, and is exposed through a "frame diagnose" command. It is also used to provide symbolic information, when available, in the event of a crash. The algorithm is very rudimentary, and it needs a bunch of work, including - better parsing for assembly, preferably with help from LLVM - support for non-Apple platforms - cleanup of the algorithm core, preferably to make it all work in terms of Operands instead of register/offset pairs - improvement of the GetExpressioPath() logic to make prettier expression paths, and - better handling of vtables. I welcome all suggestios, improvements, and testcases. llvm-svn: 280692
* There exists at least one compiler on one platform that doesn't know how to ↵Enrico Granata2016-09-011-1/+1
| | | | | | | | assert on a std::shared_ptr<> Appease it by being very very very explicit about what I mean llvm-svn: 280328
* Change "memory find" over to using a variation of the Boyer–Moore search ↵Enrico Granata2016-09-011-16/+71
| | | | | | | | algorithm Fixes rdar://15455621 (and adds a test case for this command which - surprisingly and sadly - was not there originally) llvm-svn: 280327
* Tables of command options in LLDB benefit from hand-formatting to make itKate Stone2016-08-2620-554/+564
| | | | | | | | | | | | | easier to scan a set of options with a relatively large number of positional arguments. This commit standardizes their formatting throughout LLDB and applies surrounding directives to exempt them from being formatted by clang-format. These kinds of exemptions should be rare cases that benefit significantly from alternative formatting. They also imply a long-term obligation to maintain their format since the automated tools will not do so. llvm-svn: 279882
* Add a notification message in 'type lookup' when the current language ↵Enrico Granata2016-08-251-9/+19
| | | | | | | | doesn't yield results and one has to go across multiple languages to scan for types Fixes rdar://22422313 llvm-svn: 279784
* Decoupled Options from CommandInterpreter.Todd Fiala2016-08-1126-464/+589
| | | | | | | | | | | | | | | | Options used to store a reference to the CommandInterpreter instance in the base Options class. This made it impossible to parse options independent of a CommandInterpreter. This change removes the reference from the base class. Instead, it modifies the options-parsing-related methods to take an ExecutionContext pointer, which the options may inspect if they need to do so. Closes https://reviews.llvm.org/D23416 Reviewers: clayborg, jingham llvm-svn: 278440
* Delete Host/windows/win32.hZachary Turner2016-08-091-1/+1
| | | | | | | | | | | | | | | | | | | It's always hard to remember when to include this file, and when you do include it it's hard to remember what preprocessor check it needs to be behind, and then you further have to remember whether it's windows.h or win32.h which you need to include. This patch changes the name to PosixApi.h, which is more appropriately named, and makes it independent of any preprocessor setting. There's still the issue of people not knowing when to include this, because there's not a well-defined set of things it exposes other than "whatever is missing on Windows", but at least this should make it less painful to fix when problems arise. This patch depends on LLVM revision r278170. llvm-svn: 278177
* Typo corrections identified by codespellEd Maste2016-07-191-1/+1
| | | | | | | | | Submitted by giffunip@yahoo.com; I fixed a couple of nearby errors and incorrect changes in the patch. llvm.org/pr27634 llvm-svn: 275983
* LLDB help content has accumulated over time without a recent attempt toKate Stone2016-07-1427-670/+484
| | | | | | | | | review it for consistency, accuracy, and clarity. These changes attempt to address all of the above while keeping the text relatively terse. <rdar://problem/24868841> llvm-svn: 275485
* Added support for thread local variables on all Apple OS variants.Greg Clayton2016-07-012-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We had support that assumed that thread local data for a variable could be determined solely from the module in which the variable exists. While this work for linux, it doesn't work for Apple OSs. The DWARF for thread local variables consists of location opcodes that do something like: DW_OP_const8u (x) DW_OP_form_tls_address or DW_OP_const8u (x) DW_OP_GNU_push_tls_address The "x" is allowed to be anything that is needed to determine the location of the variable. For Linux "x" is the offset within the TLS data for a given executable (ModuleSP in LLDB). For Apple OS variants, it is the file address of the data structure that contains a pthread key that can be used with pthread_getspecific() and the offset needed. This fix passes the "x" along to the thread: virtual lldb::addr_t lldb_private::Thread::GetThreadLocalData(const lldb::ModuleSP module, lldb::addr_t tls_file_addr); Then this is passed along to the DynamicLoader::GetThreadLocalData(): virtual lldb::addr_t lldb_private::DynamicLoader::GetThreadLocalData(const lldb::ModuleSP module, const lldb::ThreadSP thread, lldb::addr_t tls_file_addr); This allows each DynamicLoader plug-in do the right thing for the current OS. The DynamicLoaderMacOSXDYLD was modified to be able to grab the pthread key from the data structure that is in memory and call "void *pthread_getspecific(pthread_key_t key)" to get the value of the thread local storage and it caches it per thread since it never changes. I had to update the test case to access the thread local data before trying to print it as on Apple OS variants, thread locals are not available unless they have been accessed at least one by the current thread. I also added a new lldb::ValueType named "eValueTypeVariableThreadLocal" so that we can ask SBValue objects for their ValueType and be able to tell when we have a thread local variable. <rdar://problem/23308080> llvm-svn: 274366
* fixits are apparently called fix-its.Jim Ingham2016-06-281-2/+2
| | | | | | <rdar://problem/26998596> llvm-svn: 273979
* Fix "frame variable" to show all variables defined in functions and any ↵Greg Clayton2016-06-091-5/+6
| | | | | | | | | | | | | | | | | | | | contained lexical blocks, even if they are static variables. For code like: int g_global = 234; int g_static = 345; int main(int argc, char **argv) { int a = 22333; static int g_int = 123; return g_global + g_static + g_int + a; } If we stop at the "return" statement, we expect to see "argc", "argv", "a" and "g_int" when we type "frame variable" since "g_int" is a locally defined static variable, but we don't expect to see "g_global" or "g_static" unless we add the -g option to "frame variable". llvm-svn: 272348
* Since our expression parser needs to locate areas of memory that are not in ↵Greg Clayton2016-06-091-8/+114
| | | | | | | | use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to override the Process::GetMemoryRegionInfo(...) function. In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly. llvm-svn: 272276
* second pass over removal of Mutex and ConditionSaleem Abdulrasool2016-05-195-50/+51
| | | | llvm-svn: 270024
* remove use of Mutex in favour of std::{,recursive_}mutexSaleem Abdulrasool2016-05-181-6/+11
| | | | | | | | | | 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
* Make LLDB print out an explicit marker when it's displaying formatters that ↵Enrico Granata2016-05-161-1/+3
| | | | | | | | are part of a disabled category Fixes rdar://26202006 llvm-svn: 269673
* [LLDB] Added support for PHI nodes to IR interpreterMarianne Mailhot-Sarrasin2016-05-122-1/+19
| | | | | | | | | | This allows expressions such as 'i == 1 || i == 2` to be executed using the IR interpreter, instead of relying on JIT code injection (which may not be available on some platforms). Patch by cameron314 Differential Revision: http://reviews.llvm.org/D19124 llvm-svn: 269340
* Keep original source path and mapped path in LineEntryTed Woodward2016-05-111-2/+2
| | | | | | | | | | | | | | | | | Summary: The "file" variable in a LineEntry was mapped using target.source-map, except when stepping through inlined code. This patch adds a new variable to LineEntry, "original_file", that contains the original file from the debug info. "file" will continue to (possibly) be mapped. Some code has been changed to use "original_file". This is code dealing with symbols. Code dealing with source files will still use "file". Reviewers, please confirm that these particular changes are correct. Tests run on Ubuntu 12.04 show no regression. Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20135 llvm-svn: 269250
* In some cases, type lookup has to deal with situations where it cannot ↵Enrico Granata2016-05-101-1/+23
| | | | | | | | | | reconstruct a compile unit or a function, but it still has a valid symbol - and it can use that in order to figure out the preferential language for lookups This is not the right thing for all clients (notably the expression parser), so put it in type lookup specific code Fixes rdar://problem/22422313 llvm-svn: 269095
* Fixed multiline expressions, and removed some dead code.Sean Callanan2016-05-092-24/+16
| | | | | | | | IOHandlerLinesUpdated() does nothing, and IOHandlerIsInputComplete should be implemented but isn't. This means that multiline expressions don't work. This patch fixes that. Test case to follow in the next commit. llvm-svn: 268970
* Add the ability to limit "source regexp" breakpoints to a particular functionJim Ingham2016-04-281-1/+11
| | | | | | | | | | | | within a source file. This isn't done, I need to make the name match smarter (right now it requires an exact match which is annoying for methods of a class in a namespace. Also, though we use it in tests all over the place, it doesn't look like we have a test for Source Regexp breakpoints by themselves, I'll add that in a follow-on patch. llvm-svn: 267834
* Add a --element-count option to the expression commandEnrico Granata2016-04-251-0/+23
| | | | | | | | | | | | | This option evaluates an expression and, if the result is of pointer type, treats it as if it was an array of that many elements and displays such elements This has a couple subtle points but is mostly as straightforward as it sounds Add a parray N <expr> alias for this new mode Also, extend the --object-description mode to do the moral equivalent of the above but display each element in --object-description mode Add a poarray N <expr> alias for this llvm-svn: 267372
* Added command prefix to new help messages to ensure that they're correctly ↵Kate Stone2016-04-211-11/+5
| | | | | | words in REPL mode. llvm-svn: 266940
* Fix a bug where LLDB would crash if 'apropos <anything>' was used after ↵Enrico Granata2016-04-201-0/+9
| | | | | | spawning an inferior process llvm-svn: 266911
* Use the FormatEntity work for great good - parse summary strings before ↵Enrico Granata2016-04-121-8/+11
| | | | | | accepting them, and fail to add any strings that fail parsing llvm-svn: 266138
* Cleanup the arguments for 'memory find' such that the help system reflects ↵Enrico Granata2016-04-121-5/+5
| | | | | | the real way to invoke it llvm-svn: 266129
* Cleanups to command alias to refer to itself as 'command alias' and not ↵Enrico Granata2016-04-081-5/+17
| | | | | | allow to make aliases starting with a - as that isn't really supported, and is most often a mistake (trying to pass options) llvm-svn: 265820
* Append a missing \nEnrico Granata2016-04-081-1/+1
| | | | llvm-svn: 265818
* Update watchpoint help to use new -s flagStephane Sezer2016-04-051-7/+7
| | | | | | | | | | | | | | Summary: Flag updated in D233237 Reviewers: spyffe, jingham, Eugene.Zelenko Subscribers: lldb-commits, sas Differential Revision: http://reviews.llvm.org/D18660 Change by Francis Ricci <fjricci@fb.com> llvm-svn: 265421
* Implement `target modules dump objfile`Adrian McCarthy2016-04-041-6/+106
| | | | | | Differential Revision: http://reviews.llvm.org/D18464 llvm-svn: 265349
* Add --help and --long-help options to 'command alias' such that one can now ↵Enrico Granata2016-03-311-7/+155
| | | | | | specify a help string for an alias as they are defining it llvm-svn: 264980
* Enhance the 'type X list' commands such that they actually alert the user if ↵Enrico Granata2016-03-301-10/+22
| | | | | | no formatters matching the constraints could be found llvm-svn: 264957
* Figure out what the fixed expression is, and print it. Added another target ↵Jim Ingham2016-03-292-1/+29
| | | | | | | | | | | | | 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
* Expose top-level Clang expressions via the command line and the API.Sean Callanan2016-03-282-0/+10
| | | | | | | | | | | | | | | | | | 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
* Use Clang's FixItHints to correct expressions with "trivial" mistakes (e.g. ↵Jim Ingham2016-03-252-1/+23
| | | | | | | | | | | | | | | "." 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
* Make it possible for language plugins to provide additional custom help for ↵Enrico Granata2016-03-241-2/+28
| | | | | | 'type lookup' llvm-svn: 264356
* 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
* Make 'type lookup' print an error message instead of complete radio silence ↵Enrico Granata2016-03-241-0/+3
| | | | | | | | 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
* Change 'apropos' such that it doesn't look into the "long help/syntax" ↵Enrico Granata2016-03-231-28/+3
| | | | | | | | | | 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
* Make it so that a command alias can actually remove the help/long help from ↵Enrico Granata2016-03-221-3/+3
| | | | | | its parent command by setting itself to an empty help string llvm-svn: 264108
* Unicode support on Win32.Zachary Turner2016-03-221-4/+6
| | | | | | | | | | | | | Win32 API calls that are Unicode aware require wide character strings, but LLDB uses UTF8 everywhere. This patch does conversions wherever necessary when passing strings into and out of Win32 API calls. Patch by Cameron Differential Revision: http://reviews.llvm.org/D17107 Reviewed By: zturner, amccarth llvm-svn: 264074
* Handle any persistent Decl in the Clang expression parser, not just types.Sean Callanan2016-03-191-1/+1
| | | | | | | | | | Persistent decls have traditionally only been types. However, we want to be able to persist more things, like functions and global variables. This changes some of the nomenclature and the lookup rules to make this possible. <rdar://problem/22864976> llvm-svn: 263864
OpenPOWER on IntegriCloud