summaryrefslogtreecommitdiff
path: root/lldb/source/Commands/CommandObjectMemory.cpp
AgeCommit message (Collapse)Author
2015-09-25Moved more Clang-specific parts of the expression parser into the Clang plugin.Sean Callanan
There are still a bunch of dependencies on the plug-in, but this helps to identify them. There are also a few more bits we need to move (and abstract, for example the ClangPersistentVariables). llvm-svn: 248612
2015-09-22Rename clang_type_t to opaque_compiler_type_t.Bruce Mitchener
Summary: This is no longer related to Clang and is just an opaque pointer to data for a compiler type. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13039 llvm-svn: 248288
2015-08-24Final bit of type system cleanup that abstracts declaration contexts into ↵Greg Clayton
lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
2015-08-11ClangASTType is now CompilerType.Greg Clayton
This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc). llvm-svn: 244689
2015-08-11First step in getting LLDB ready to support multiple different type systems.Greg Clayton
This is the work done by Ryan Brown from http://reviews.llvm.org/D8712 that makes a TypeSystem class and abstracts types to be able to use a type system. All tests pass on MacOSX and passed on linux the last time this was submitted. llvm-svn: 244679
2015-08-03Jim suggested to use eArgTypeAddressOrExpression for the addresses that ↵Enrico Granata
'memory find' takes llvm-svn: 243902
2015-08-03Fix the memory find command such that it can actually take an expressionEnrico Granata
llvm-svn: 243893
2015-06-08Revert "Introduce a TypeSystem interface to support adding non-clang languages."Pavel Labath
This seems to break expression evaluation on the linux build. llvm-svn: 239366
2015-06-08Introduce a TypeSystem interface to support adding non-clang languages.Pavel Labath
Reviewers: clayborg Reviewed By: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D8712 Original Author: Ryan Brown <ribrdb@google.com> llvm-svn: 239360
2015-05-29Don't #include "lldb-python.h" from anywhere.Zachary Turner
Since interaction with the python interpreter is moving towards being more isolated, we won't be able to include this header from normal files anymore, all includes of it should be localized to the python library which will live under source/bindings/API/Python after a future patch. None of the files that were including this header actually depended on it anyway, so it was just a dead include in every single instance. llvm-svn: 238581
2015-05-27Add support for custom commands to set flags on themselvesEnrico Granata
This works for Python commands defined via a class (implement get_flags on your class) and C++ plugin commands (which can call SBCommand::GetFlags()/SetFlags()) Flags allow features such as not letting the command run if there's no target, or if the process is not stopped, ... Commands could always check for these things themselves, but having these accessible via flags makes custom commands more consistent with built-in ones llvm-svn: 238286
2015-05-13Fixed a ton of gcc compile warningsVince Harron
Removed some unused variables, added some consts, changed some casts to const_cast. I don't think any of these changes are very controversial. Differential Revision: http://reviews.llvm.org/D9674 llvm-svn: 237218
2015-04-06If memory read does not find a NULL terminator, still print whatever it ↵Enrico Granata
gathered instead of just NOP'ing out However, remark that this is an incomplete chunk of data by still emitting the "no NULL found" warning rdar://20330073 llvm-svn: 234194
2015-03-03Don't #include FormatManager.h from Debugger.hZachary Turner
Debugger.h is a huge file that gets included everywhere, and FormatManager.h brings in a ton of unnecessary stuff and doesn't even use anything from it in the header. llvm-svn: 231161
2015-03-03Don't #include ClangPersistentVariables.h from Process.hZachary Turner
Nothing from this header file was even being referenced in Process.h anyway, so it was a completely unnecessary include. llvm-svn: 231131
2015-02-20Refactor OptionValue::SetValueFromCString to use llvm::StringRefPavel Labath
Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D7676 llvm-svn: 230005
2015-02-03Small fix for the "memory write -i filename" command -- if the user fails to ↵Jason Molenda
specify the number of bytes to write into the inferior process, the "default byte size" will be 1. In that case, we want to copy the entire file into memory. The code was looking for a default byte size of 0 to indicate that the user had not provided a specific # of bytes to copy; adjust that to 1 to match the actual default value. <rdar://problem/18074973> llvm-svn: 228067
2015-01-28Preparatory infrastructural work to support dynamically determining sizes of ↵Enrico Granata
ObjC types via the runtime This is necessary because the byte size of an ObjC class type is not reliably statically knowable (e.g. because superclasses sit deep in frameworks that we have no debug info for) The lack of reliable size info is a problem when trying to freeze-dry an ObjC instance (not the pointer, the pointee) This commit lays the foundation for having language runtimes help in figuring out byte sizes, and having ClangASTType ask for runtime help No feature change as no runtime actually implements the logic, and nowhere is an ExecutionContext passed in yet llvm-svn: 227274
2015-01-15Moved Args::StringToXIntYZ to StringConvert::ToXIntYZVince Harron
The refactor was motivated by some comments that Greg made http://reviews.llvm.org/D6918 and also to break a dependency cascade that caused functions linking in string->int conversion functions to pull in most of lldb llvm-svn: 226199
2014-09-29Very minimal support 24-bit kalimbas. Vanilla "memory read" for data sectionsMatthew Gardiner
works, as do breakpoints, run and pause, display zeroth frame. See http://reviews.llvm.org/D5503 for a fuller description of the changes in this commit. llvm-svn: 218596
2014-09-06Correct copied error messageEd Maste
Patch by Remco Verhoef. llvm-svn: 217312
2014-09-04ASan malloc/free history threadsKuba Brecka
Reviewed at http://reviews.llvm.org/D4596 llvm-svn: 217116
2014-07-10Reapply typo fix.Bruce Mitchener
This was lost in the re-merging of command validation changes. llvm-svn: 212721
2014-07-09Revert "Fix broken tests due to new error output."Zachary Turner
This reverts commit ec7c94f8e6860968d384b578e5564a9c55c80b4a and re-enables OptionValidators. llvm-svn: 212627
2014-07-08Fix typos.Bruce Mitchener
llvm-svn: 212553
2014-07-08Fix broken tests due to new error output.Todd Fiala
This reverses out the options validators changes. We'll get these back in once the changes to the output can be resolved. Restores broken tests on FreeBSD, Linux, MacOSX. Changes reverted: r212500, r212317, r212290. llvm-svn: 212543
2014-07-03Adds the notion of an OptionValidator.Zachary Turner
The purpose of the OptionValidator is to determine, based on some arbitrary set of conditions, whether or not a command option is valid for a given debugger state. An example of this might be to selectively disable or enable certain command options that don't apply to a particular platform. This patch contains no functional change, and does not actually make use of an OptionValidator for any purpose yet. A follow-up patch will begin to add the logic and users of OptionValidator. Reviewed by: Greg Clayton, Jim Ingham Differential Revision: http://reviews.llvm.org/D4369 llvm-svn: 212290
2014-03-08Remove %zx in printf (only GCC supports it, not MSVC).Virgile Bello
llvm-svn: 203349
2014-03-03"size_t" isn't always 64 bit, it is 32 bit on 32 bit systems. All printf ↵Greg Clayton
style statements that were assuming size_t were 64 bit were changed, and they were also changed to display them as unsigned values as "size_t" isn't signed. If you print anything with 'size_t', please cast it to "uint64_t" in the printf and use PRIu64 or PRIx64. llvm-svn: 202738
2014-03-03Fix Windows build using portable types for formatting the log outputsDeepak Panickal
llvm-svn: 202723
2013-11-13Minor improvement to the "memory find" commandEnrico Granata
Remove the --do-read option, and always provide a small dump of memory at each match spot Add a --dump-offset (-o) option, to specify a byte offset from which to start dumping relative to the matching address The real solution is to actually provide the format options found on "memory read" and use those as the key to actually printing memory upon each find That, however, requires a little refactoring work, so put this in for now until I get a chance to do the required shuffling around of moving parts llvm-svn: 194600
2013-11-13Small typos in previous commitEnrico Granata
llvm-svn: 194546
2013-11-13<rdar://problem/14322677>Enrico Granata
Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-04Roll back the changes I made in r193907 which created a new FrameJason Molenda
pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-02Add a new base class, Frame. It is a pure virtual function whichJason Molenda
defines a protocol that all subclasses will implement. StackFrame is currently the only subclass and the methods that Frame vends are nearly identical to StackFrame's old methods. Update all callers to use Frame*/Frame& instead of pointers to StackFrames. This is almost entirely a mechanical change that touches a lot of the code base so I'm committing it alone. No new functionality is added with this patch, no new subclasses of Frame exist yet. I'll probably need to tweak some of the separation, possibly moving some of StackFrame's methods up in to Frame, but this is a good starting point. <rdar://problem/15314068> llvm-svn: 193907
2013-10-31Fix the format warnings.Sylvestre Ledru
In almost all cases, the misuse is about "%lu" being used instead of the correct "%zu" (even though these are compatible on 64-bit platforms in practice). There are even a couple of cases where "%ld" (ie., signed int) is used instead of "%zu", and one where "%lu" is used instead of "%" PRIu64. Fixes bug #17551. Patch by "/dev/humancontroller" llvm-svn: 193832
2013-10-29<rdar://problem/15296388>Enrico Granata
Fix a crasher that would occur if one tried to read memory as characters of some size != 1, e.g. x -f c -s 10 buffer This commit tries to do the right thing and uses the byte-size as the number of elements, unless both are specified and the number of elements is != 1 In this latter case (e.g. x -f c -s 10 -c 3 buffer) one could multiply the two and read 30 characters, but it seems a stretch in mind reading. llvm-svn: 193659
2013-09-30<rdar://problem/14393032>Enrico Granata
DumpValueObject() 2.0 This checkin restores pre-Xcode5 functionality to the "po" (expr -O) command: - expr now has a new --description-verbosity (-v) argument, which takes either compact or full as a value (-v is the same as -vfull) When the full mode is on, "po" will show the extended output with type name, persistent variable name and value, as in (lldb) expr -O -v -- foo (id) $0 = 0x000000010010baf0 { 1 = 2; 2 = 3; } When -v is omitted, or -vcompact is passed, the Xcode5-style output will be shown, as in (lldb) expr -O -- foo { 1 = 2; 2 = 3; } - for a non-ObjectiveC object, LLDB will still try to retrieve a summary and/or value to display (lldb) po 5 5 -v also works in this mode (lldb) expr -O -vfull -- 5 (int) $4 = 5 On top of that, this is a major refactoring of the ValueObject printing code. The functionality is now factored into a ValueObjectPrinter class for easier maintenance in the future DumpValueObject() was turned into an instance method ValueObject::Dump() which simply calls through to the printer code, Dump_Impl has been removed Test case to follow llvm-svn: 191694
2013-09-05Add OptionParser.hVirgile Bello
llvm-svn: 190063
2013-08-28Cleanup/rearrange includes:Virgile Bello
- factorize unistd.h and stdbool.h in lldb-types.h. - Add <functional> and <string> where required. llvm-svn: 189477
2013-07-24<rdar://problem/14521548>Greg Clayton
Fixed a crasher where if you accidentally specify a size that is too large when reading memory, LLDB would crash. llvm-svn: 187060
2013-07-11Huge change to clean up types.Greg Clayton
A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-06-11<rdar://problem/13779789>Enrico Granata
Allow memory read -t to take persistent types (those defined with expression struct $....) llvm-svn: 183766
2013-06-11Remove eFormatHalfFloat as it isn't needed. eFormatFloat should be used and ↵Greg Clayton
the byte size will tell us how to display it. llvm-svn: 183755
2013-06-11<rdar://problem/12783351>Enrico Granata
Add support for half-floats, as specified by IEEE-754-2008 With this checkin, you can now say: (lldb) x/7hf foo to read 7 half-floats at address foo llvm-svn: 183716
2013-06-04<rdar://problem/13239809>Enrico Granata
Two things: 1) fixing a bug where memory read was not clearing the m_force flag after it was passed, so that subsequent memory reads would not need to be forced even if over boundary 2) adding a setting target.max-memory-read-size that you can set instead of the hardcoded 1024 bytes limit we had before llvm-svn: 183276
2013-05-21<rdar://problem/13925432>Enrico Granata
A user request such as: memory read -fc -s10 -c1 *charPtrPtr would cause us to crash upon trying to read 1 char of size 10 from memory This request is now translated into: memory read -fc -s1 -c10 *charPtrPtr (i.e. read 10 chars of size 1 from memory) which is probably also what the user originally wanted llvm-svn: 182398
2013-03-27Don't use a "uintptr_t" for the metadata key, use a "void *". This removes ↵Greg Clayton
all of the casts that were being used and cleans the code up a bit. Also added the ability to dump the metadata. llvm-svn: 178113
2013-03-26Our commands that end up displaying a ValueObject as part of their workflow ↵Enrico Granata
use OptionGroupValueObjectDisplay as their currency for deciding the final representation ValueObjects themselves use DumpValueObjectOptions as the currency for the same purpose The code to convert between these two units was replicated (to varying degrees of correctness) in several spots in the code This checkin provides one and only one (and hopefully correct :-) entry point for this conversion llvm-svn: 178044
2013-03-23Set the correct byte size for complex integer (-fI) memory reads.Jason Molenda
<rdar://problem/12281172> llvm-svn: 177814