instead of the __repr__. __repr__ is a function that should return an
expression that can be used to recreate an python object and we were using
it to just return a human readable string.
Fixed a crasher when using the new implementation of SBValue::Cast(SBType).
Thread hardened lldb::SBValue and lldb::SBWatchpoint and did other general
improvements to the API.
Fixed a crasher in lldb::SBValue::GetChildMemberWithName() where we didn't
correctly handle not having a target.
llvm-svn: 149743
due to RTTI worries since llvm and clang don't use RTTI, but I was able to
switch back with no issues as far as I can tell. Once the RTTI issue wasn't
an issue, we were looking for a way to properly track weak pointers to objects
to solve some of the threading issues we have been running into which naturally
led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared
pointer from just a pointer, which is also easily solved using the
std::tr1::enable_shared_from_this class.
The main reason for this move back is so we can start properly having weak
references to objects. Currently a lldb_private::Thread class has a refrence
to its parent lldb_private::Process. This doesn't work well when we now hand
out a SBThread object that contains a shared pointer to a lldb_private::Thread
as this SBThread can be held onto by external clients and if they end up
using one of these objects we can easily crash.
So the next task is to start adopting std::tr1::weak_ptr where ever it makes
sense which we can do with lldb_private::Debugger, lldb_private::Target,
lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and
many more objects now that they are no longer using intrusive ref counted
pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive
pointers).
llvm-svn: 149207
The previous approach to controlling the recursion was doing it from
outside the function which is not reliable. Now it is being done inside
the function. This might not solve all of the crashes that we were seeing
since there are other functions that clear the bit that indicates that
the summary is in the process of being generated, but it might solve some.
llvm-svn: 147741
as part of the thread format output.
Currently this is only done for the ThreadPlanStepOut.
Add a convenience API ABI::GetReturnValueObject.
Change the ValueObject::EvaluationPoint to BE an ExecutionContextScope, rather than
trying to hand out one of its subsidiary object's pointers. That way this will always
be good.
llvm-svn: 146806
hard to ensure it doesn't get invalidated out from under us. Instead look it up from the ThreadID
and StackID when asked for it.
<rdar://problem/10554409>
llvm-svn: 146309
in the same hashed format as the ".apple_names", but they map objective C
class names to all of the methods and class functions. We need to do this
because in the DWARF the methods for Objective C are never contained in the
class definition, they are scattered about at the translation unit level and
they don't even have attributes that say the are contained within the class
itself.
Added 3 new formats which can be used to display data:
eFormatAddressInfo
eFormatHexFloat
eFormatInstruction
eFormatAddressInfo describes an address such as function+offset and file+line,
or symbol + offset, or constant data (c string, 2, 4, 8, or 16 byte constants).
The format character for this is "A", the long format is "address".
eFormatHexFloat will print out the hex float format that compilers tend to use.
The format character for this is "X", the long format is "hex float".
eFormatInstruction will print out disassembly with bytes and it will use the
current target's architecture. The format character for this is "i" (which
used to be being used for the integer format, but the integer format also has
"d", so we gave the "i" format to disassembly), the long format is
"instruction".
Mate the lldb::FormatterChoiceCriterion enumeration private as it should have
been from the start. It is very specialized and doesn't belong in the public
API.
llvm-svn: 143114
"const char *" is NULL. Also cleaned up the display of strings when you have
an array of chars that are all NULL. Previously we were showing: ""...
We now show: ""
llvm-svn: 141223
shared pointers.
Changed the ExecutionContext over to use shared pointers for
the target, process, thread and frame since these objects can
easily go away at any time and any object that was holding onto
an ExecutionContext was running the risk of using a bad object.
Now that the shared pointers for target, process, thread and
frame are just a single pointer (they all use the instrusive
shared pointers) the execution context is much safer and still
the same size.
Made the shared pointers in the the ExecutionContext class protected
and made accessors for all of the various ways to get at the pointers,
references, and shared pointers.
llvm-svn: 140298
__attribute__ format so the compiler knows that this method takes
printf style formatter arguments and checks that it's being used
correctly. Fix a couple dozen incorrect SetErrorStringWithFormat()
calls throughout the sources.
llvm-svn: 140115
Reduced the amount of memory required to avoid loops in DumpPrintableRepresentation() from 32 bits down to 1 bit
- Additionally, disallowed creating summary strings of the form ${var%S} which did nothing but cause endless loops by definition
llvm-svn: 139201
- introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from
a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored
in frozen objects ; now such reads transparently move from host to target as required
- as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also
removed code that enabled to recognize an expression result VO as such
- introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO
representing a T* or T[], and doing dereferences transparently
in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData
- as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it
en lieu of doing the raw read itself
- introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers,
this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory)
in public layer this returns an SBData, just like GetPointeeData()
- introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData
the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any
of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values
- added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing
Solved a bug where global pointers to global variables were not dereferenced correctly for display
New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128
Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command
Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type
of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file
addresses that generate file address children UNLESS we have a live process)
Updated help text for summary-string
Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers
Edited the syntax and help for some commands to have proper argument types
llvm-svn: 139160
register names when dumping variable locations and location lists. Also did
some cleanup where "int" types were being used for "lldb::RegisterKind"
values.
llvm-svn: 138988
Renamed format "signed decimal" to be "decimal". "unsigned decimal" remains unchanged:
- the name "signed decimal" was interfering with symbol %S (use summary) in summary strings.
because of the way summary strings are implemented, this did not really lead to a bug, but
simply to performing more steps than necessary to display a summary. this is fixed.
Documentation improvements (more on synthetic children, some information on filters). This is still a WIP.
llvm-svn: 138384
plug-ins are add on plug-ins for the lldb_private::Process class that can add
thread contexts that are read from memory. It is common in kernels to have
a lot of threads that are not currently executing on any cores (JTAG debugging
also follows this sort of thing) and are context switched out whose state is
stored in memory data structures. Clients can now subclass the OperatingSystem
plug-ins and then make sure their Create functions correcltly only enable
themselves when the right binary/target triple are being debugged. The
operating system plug-ins get a chance to attach themselves to processes just
after launching or attaching and are given a lldb_private::Process object
pointer which can be inspected to see if the main executable, target triple,
or any shared libraries match a case where the OS plug-in should be used.
Currently the OS plug-ins can create new threads, define the register contexts
for these threads (which can all be different if desired), and populate and
manage the thread info (stop reason, registers in the register context) as
the debug session goes on.
llvm-svn: 138228
e.g. you may get "foo_class @ 0x123456" when typing "type summary add -f ${var} foo_class"
- Added a new special formatting token %T for summaries. This shows the type of the object.
Using it, the new "type @ location" summary could be manually generated by writing ${var%T} @ ${var%L}
- Bits and pieces required to support "frame variable array[n-m]"
The feature is not enabled yet because some additional design and support code is required, but the basics
are getting there
- Fixed a potential issue where a ValueObjectSyntheticFilter was not holding on to its SyntheticChildrenSP
Because of the way VOSF are being built now, this has never been an actual issue, but it is still sensible for
a VOSF to hold on to the SyntheticChildrenSP as well as to its FrontEnd
llvm-svn: 138080
- reorganizing classes layout to have public part first
Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception
- avoiding methods in the form T foo() { code; } all on one-line
- moving method implementations from .h to .cpp whenever feasible
Templatized code is an exception and so are very small methods
- generally, adhering to coding conventions followed project-wide
Functional changes:
- fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed
The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer
Accordingly fixed test cases and added a new test case
llvm-svn: 137944
- all instances of "vobj" have been renamed to "valobj"
- class Debugger::Formatting has been renamed to DataVisualization (defined in FormatManager.h/cpp)
The interface to this class has not changed
- FormatCategory now uses ConstString's as keys to the navigators instead of repeatedly casting
from ConstString to const char* and back all the time
Next step is making the same happen for categories themselves
- category gnu-libstdc++ is defined in the constructor for a FormatManager
The source code for it is defined in gnu_libstdcpp.py, drawn from examples/synthetic at compile time
All references to previous 'osxcpp' name have been removed from both code and file names
Functional changes:
- the name of the option to use a summary string for 'type summary add' has changed from the previous --format-string
to the new --summary-string. It is expected that the short option will change from -f to -s, and -s for --python-script
will become -o
llvm-svn: 137886
Also change the SourceInitFile to look for .lldb-<APPNAME> and source that
preferentially if it exists.
Also made the breakpoint site report its address as well as its breakpoint number
when it gets hit and can't find any the associated locations (usually because the
breakpoint got disabled or deleted programmatically between the time it was hit
and reported.)
Changed ThreadPlanCallFunction to initialize the ivar m_func in the initializers of the
constructor, rather than waiting to initialize till later on in the function.
Fixed a bug where if you make an SBError and the ask it Success, it returns false.
Fixed ValueObject::ResolveValue so that it resolves a temporary value, rather than
overwriting the one in the value object.
llvm-svn: 137536
cause extra shared pointer references to one or more modules to be leaked.
This would cause many object files to stay around the life of LLDB, so after
a recompile and rexecution, we would keep adding more and more memory. After
fixing the leak, we found many cases where leaked stack frames were still
being used and causing crashes in the test suite. These are now all resolved.
llvm-svn: 137516
The converse is also true: an error is shown when the user tries to add a synthetic provider to a category that already has a filter for the same type
llvm-svn: 137493
*New setting target.max-children-count gives an upper-bound to the number of child objects that will be displayed at each depth-level
This might be a breaking change in some scenarios. To override the new limit you can use the --show-all-children (-A) option
to frame variable or increase the limit in your lldbinit file
*Command "type synthetic" has been split in two:
- "type synthetic" now only handles Python synthetic children providers
- the new command "type filter" handles filters
Because filters and synthetic providers are both ways to replace the children of a ValueObject, only one can be effective at any given time.
llvm-svn: 137416
Access to synthetic children by name:
if your object has a synthetic child named foo you can now type
frame variable object.foo (or ->foo if you have a pointer)
and that will print the value of the synthetic child
(if your object has an actual child named foo, the actual child prevails!)
this behavior should also work in summaries, and you should be able to use
${var.foo} and ${svar.foo} interchangeably
(but using svar.foo will mask an actual child named foo)
llvm-svn: 137314
event is removed. Also use the return value of asynchronous breakpoint callbacks, they get checked before, and override the
breakpoint conditions.
Added ProcessModInfo class, to unify "stop_id generation" and "memory modification generation", and use where needed.
llvm-svn: 137102
if your datatype provides synthetic children, "frame variable object[index]" should now do the right thing
in cases where the above syntax would have been rejected before, i.e.
object is not a pointer nor an array (frame variable ignores potential overload of [])
object is a pointer to an Objective-C class (which cannot be dereferenced)
expression will still run operator[] if available and complain if it cannot do so
synthetic children by name do not work yet
llvm-svn: 137097
- accordingly, the test cases for the synthetic providers for the std:: containers have been edited to use
${svar%#} instead of ${svar.len} to print out the count of elements ; the .len synthetic child has been
removed from the synthetic providers
The synthetic children providers for the std:: containers now return None when asked for children indexes >= num_children()
Basic code to support filter names based on regular expressions (WIP)
llvm-svn: 136862
The synthetic children providers now use the new (safer) APIs to get the values of objects
As a side effect, fixed an issue in ValueObject where ResolveValue() was not always updating the value before reading it
llvm-svn: 136861
- see the test case in lang/objc/objc-dynamic-value for an example
Objective-C dynamic type lookup now works for every Objective-C type
- previously, true dynamic lookup was only performed for type id
llvm-svn: 136763
Fixed a bug where Objective-C variables coming out of the expression parser could crash the Python synthetic providers:
- expression parser output has a "frozen data" component, which is a byte-exact copy of the value (in host memory),
if trying to read into memory based on the host address, LLDB would crash. we are now passing the correct (target)
pointer to the Python code
Objective-C "id" variables are now formatted according to their dynamic type, if the -d option to frame variable is used:
- Code based on the Objective-C 2.0 runtime is used to obtain this information without running code on the target
llvm-svn: 136695
- Completely new implementation of SBType
- Various enhancements in several other classes
Python synthetic children providers for std::vector<T>, std::list<T> and std::map<K,V>:
- these return the actual elements into the container as the children of the container
- basic template name parsing that works (hopefully) on both Clang and GCC
- find them in examples/synthetic and in the test suite in functionalities/data-formatter/data-formatter-python-synth
New summary string token ${svar :
- the syntax is just the same as in ${var but this new token lets you read the values
coming from the synthetic children provider instead of the actual children
- Python providers above provide a synthetic child len that returns the number of elements
into the container
Full bug fix for the issue in which getting byte size for a non-complete type would crash LLDB
Several other fixes, including:
- inverted the order of arguments in the ClangASTType constructor
- EvaluationPoint now only returns SharedPointer's to Target and Process
- the help text for several type subcommands now correctly indicates argument-less options as such
llvm-svn: 136504
- you can now define a Python class as a synthetic children producer for a type
the class must adhere to this "interface":
def __init__(self, valobj, dict):
def get_child_at_index(self, index):
def get_child_index(self, name):
then using type synth add -l className typeName
(e.g. type synth add -l fooSynthProvider foo)
(This is still WIP with lots to be added)
A small test case is available also as reference
llvm-svn: 135865
(e.g. ${var%S}). this might already be the default if your variable is of an aggregate type
new feature: synthetic filters. you can restrict the number of children for your variables to only a meaningful subset
- the restricted list of children obeys the typical rules (e.g. summaries prevail over children)
- one-line summaries show only the filtered (synthetic) children, if you type an expanded summary string, or you use Python scripts, all the real children are accessible
- to provide a synthetic children list use the "type synth add" command, as in:
type synth add foo_type --child varA --child varB[0] --child varC->packet->flags[1-4]
(you can use ., ->, single-item array operator [N] and bitfield operator [N-M]; array slice access is not supported, giving simplified names to expression paths is not supported)
- a new -S option to frame variable and target variable lets you override synthetic children and instead show real ones
llvm-svn: 135731
Used hand merge to apply the diffs. I did not apply the diffs for FormatManager.h and
the diffs for memberwise initialization for ValueObject.cpp because they changed since.
I will ask my colleague to apply them later.
llvm-svn: 135508
The "systemwide summaries" feature has been removed and replaced with a more general and
powerful mechanism.
Categories:
- summaries can now be grouped into buckets, called "categories" (it is expected that categories
correspond to libraries and/or runtime environments)
- to add a summary to a category, you can use the -w option to type summary add and give
a category name (e.g. type summary add -f "foo" foo_t -w foo_category)
- categories are by default disabled, which means LLDB will not look into them for summaries,
to enable a category use "type category enable". once a category is enabled, LLDB will
look into that category for summaries. the rules are quite trivial: every enabled category
is searched for an exact match. if an exact match is nowhere to be found, any match is
searched for in every enabled category (whether it involves cascading, going to base classes,
...). categories are searched into the order in which they were enabled (the most recently
enabled category first, then the second most and so on..)
- by default, most commands that deal with summaries, use a category named "default" if no
explicit -w parameter is given (the observable behavior of LLDB should not change when
categories are not explicitly used)
- the systemwide summaries are now part of a "system" category
llvm-svn: 135463
- help type summary add now gives some hints on how to use it
frame variable and target variable now have a --no-summary-depth (-Y) option:
- simply using -Y without an argument will skip one level of summaries, i.e.
your aggregate types will expand their children and display no summary, even
if they have one. children will behave normally
- using -Y<int>, as in -Y4, -Y7, ..., will skip as many levels of summaries as
given by the <int> parameter (obviously, -Y and -Y1 are the same thing). children
beneath the given depth level will behave normally
-Y0 is the same as omitting the --no-summary-depth parameter entirely
This option replaces the defined-but-unimplemented --no-summary
llvm-svn: 135336
Greg Clayton