lldb.SBValueList now exposes the len() method and also allows item access:
lldb.SBValueList[<int>] - where <int> is an integer index into the list, returns a single lldb.SBValue which might be empty if the index is out of range
lldb.SBValueList[<str>] - where <str> is the name to look for, returns a list() of lldb.SBValue objects with any matching values (the list might be empty if nothing matches)
lldb.SBValueList[<re>] - where <re> is a compiles regular expression, returns a list of lldb.SBValue objects for containing any matches or a empty list if nothing matches
lldb.SBFrame now exposes:
lldb.SBFrame.variables => SBValueList of all variables that are in scope
lldb.SBFrame.vars => see lldb.SBFrame.variables
lldb.SBFrame.locals => SBValueList of all variables that are locals in the current frame
lldb.SBFrame.arguments => SBValueList of all variables that are arguments in the current frame
lldb.SBFrame.args => see lldb.SBFrame.arguments
lldb.SBFrame.statics => SBValueList of all static variables
lldb.SBFrame.registers => SBValueList of all registers for the current frame
lldb.SBFrame.regs => see lldb.SBFrame.registers
Combine any of the above properties with the new lldb.SBValueList functionality
and now you can do:
y = lldb.frame.vars['rect.origin.y']
or
vars = lldb.frame.vars
for i in range len(vars):
print vars[i]
Also expose "lldb.SBFrame.var(<str>)" where <str> can be en expression path
for any variable or child within the variable. This makes it easier to get a
value from the current frame like "rect.origin.y". The resulting value is also
not a constant result as expressions will return, but a live value that will
continue to track the current value for the variable expression path.
lldb.SBValue now exposes:
lldb.SBValue.unsigned => unsigned integer for the value
lldb.SBValue.signed => a signed integer for the value
llvm-svn: 149684
Currently, no code is using this feature, since we can hopefully rely on the new template support in SBType to get the same stuff done, but the support is there just in case it turns out to be useful for some future need.
llvm-svn: 149661
uint32_t
SBType::GetNumberOfTemplateArguments ();
lldb::SBType
SBType::GetTemplateArgumentType (uint32_t idx);
lldb::TemplateArgumentKind
SBType::GetTemplateArgumentKind (uint32_t idx);
Some lldb::TemplateArgumentKind values don't have a corresponding SBType
that will be returned from SBType::GetTemplateArgumentType(). This will
help our data formatters do their job by being able to find out the
type of template params and do smart things with those.
llvm-svn: 149658
When used in conjunction with --inline-children, this option will cause the names of the values to be omitted from the output. This can be beneficial in cases such as vFloat, where it will compact the representation from
([0]=1,[1]=2,[2]=3,[3]=4) to (1, 2, 3, 4).
Added a test case to check that the new option works correctly.
Also took some time to revisit SummaryFormat and related classes and tweak them for added readability and maintainability.
Finally, added a new class name to which the std::string summary should be applied.
llvm-svn: 149644
should use Target::ReadMemory() call to read from the file section offset address.
Also remove the @expectedFailure decorator..
'target variable' command fails if the target program has been run
rdar://problem/9763907
llvm-svn: 149629
otherwise we will have a launched process stopped at the entry point and
it will get reparented when debugserver goes away and we won't be able to
kill the process later.
llvm-svn: 149622
a type when we have a forward declaration. We always have found a
type by basename, but now we also compare the decl context of the
die we are trying to complete with the matches we find from the accelerator
tables to ensure we get the right one.
llvm-svn: 149593
You can now access a frame in a thread using:
lldb.SBThread.frame[int] -> lldb.SBFrame object for a frame in a thread
Where "int" is an integer index. You can also access a list object with all of
the frames using:
lldb.SBThread.frames => list() of lldb.SBFrame objects
All SB objects that give out SBAddress objects have properties named "addr"
lldb.SBInstructionList now has the following convenience accessors for len() and
instruction access using an index:
insts = lldb.frame.function.instructions
for idx in range(len(insts)):
print insts[idx]
Instruction lists can also lookup an isntruction using a lldb.SBAddress as the key:
pc_inst = lldb.frame.function.instructions[lldb.frame.addr]
lldb.SBProcess now exposes:
lldb.SBProcess.is_alive => BOOL Check if a process is exists and is alive
lldb.SBProcess.is_running => BOOL check if a process is running (or stepping):
lldb.SBProcess.is_running => BOOL check if a process is currently stopped or crashed:
lldb.SBProcess.thread[int] => lldb.SBThreads for a given "int" zero based index
lldb.SBProcess.threads => list() containing all lldb.SBThread objects in a process
SBInstruction now exposes:
lldb.SBInstruction.mnemonic => python string for instruction mnemonic
lldb.SBInstruction.operands => python string for instruction operands
lldb.SBInstruction.command => python string for instruction comment
SBModule now exposes:
lldb.SBModule.uuid => uuid.UUID(), an UUID object from the "uuid" python module
lldb.SBModule.symbol[int] => lldb.Symbol, lookup symbol by zero based index
lldb.SBModule.symbol[str] => list() of lldb.Symbol objects that match "str"
lldb.SBModule.symbol[re] => list() of lldb.Symbol objecxts that match the regex
lldb.SBModule.symbols => list() of all symbols in a module
SBAddress objects can now access the current load address with the "lldb.SBAddress.load_addr"
property. The current "lldb.target" will be used to try and resolve the load address.
Load addresses can also be set using this accessor:
addr = lldb.SBAddress()
addd.load_addr = 0x123023
Then you can check the section and offset to see if the address got resolved.
SBTarget now exposes:
lldb.SBTarget.module[int] => lldb.SBModule from zero based module index
lldb.SBTarget.module[str] => lldb.SBModule by basename or fullpath or uuid string
lldb.SBTarget.module[uuid.UUID()] => lldb.SBModule whose UUID matches
lldb.SBTarget.module[re] => list() of lldb.SBModule objects that match the regex
lldb.SBTarget.modules => list() of all lldb.SBModule objects in the target
SBSymbol now exposes:
lldb.SBSymbol.name => python string for demangled symbol name
lldb.SBSymbol.mangled => python string for mangled symbol name or None if there is none
lldb.SBSymbol.type => lldb.eSymbolType enum value
lldb.SBSymbol.addr => SBAddress object that represents the start address for this symbol (if there is one)
lldb.SBSymbol.end_addr => SBAddress for the end address of the symbol (if there is one)
lldb.SBSymbol.prologue_size => pythin int containing The size of the prologue in bytes
lldb.SBSymbol.instructions => SBInstructionList containing all instructions for this symbol
SBFunction now also has these new properties in addition to what is already has:
lldb.SBFunction.addr => SBAddress object that represents the start address for this function
lldb.SBFunction.end_addr => SBAddress for the end address of the function
lldb.SBFunction.instructions => SBInstructionList containing all instructions for this function
SBFrame now exposes the SBAddress for the frame:
lldb.SBFrame.addr => SBAddress which is the section offset address for the current frame PC
These are all in addition to what was already added. Documentation and website
updates coming soon.
llvm-svn: 149489
(lldb) script
>>> frames = lldb.thread.frames
>>> for frame in frames:
... print frame
Also changed all of the "__repr__" methods to strip any trailing newline characters so we don't end up with entra newlines.
llvm-svn: 149466
o Symbols.cpp:
Emit a warning message when dSYM does not match the binary.
o warnings/uuid:
Added regression test case.
o lldbtest.py:
Modified to allow test case writer to demand that the build command does not begin
with a clean first; required to make TestUUIDMismatchWanring.py work.
rdar://problem/10515708
llvm-svn: 149465
lldb.value()
It it designed to be given a lldb.SBValue object and it allows natural
use of a variable value:
pt = lldb.value(lldb.frame.FindVariable("pt"))
print pt
print pt.x
print pt.y
pt = lldb.frame.FindVariable("rectangle_array")
print rectangle_array[12]
print rectangle_array[5].origin.x
Note that array access works just fine and works on arrays or pointers:
pt = lldb.frame.FindVariable("point_ptr")
print point_ptr[5].y
Also note that pointer child accesses are done using a "." instead of "->":
print point_ptr.x
llvm-svn: 149464
We previously weren't catching that SBValue::Cast(...) would crash
if we had an invalid (empty) SBValue object.
Cleaned up the SBType API a bit.
llvm-svn: 149447
instances to not pthread_cancel the read threads and wreak havoc on the mutex
in our ConnectionFileDescriptor class.
Also cleaned up some shutdown delays.
llvm-svn: 149355
environment variable before starting the test runner which executes the test cases and
may spawn child processes. An example:
./dotest.py -u MY_ENV1 -u MY_ENV2 -v -p TestWatchLocationWithWatchSet.py
llvm-svn: 149304
Also add test cases for watching a variable as well as a location expressed as an expression.
o TestMyFirstWatchpoint.py:
Modified to test "watchpoint set -w write global".
o TestWatchLocationWithWatchSet.py:
Added to test "watchpoint set -w write -x 1 g_char_ptr + 7" where a contrived example program
with several threads is supposed to only access the array index within the range [0..6], but
there's some misbehaving thread writing past the range.
rdar://problem/10701761
llvm-svn: 149280
sbvalue.value (<SBValue>)
sbvalue.variable (<SBValue>)
Initialize both with a lldb.SBValue
sbvalue.value() make all sorts of convenience properties. Type "help(sbvalue.value)"
in the embedded python interpreter to see what is available.
sbvalue.variable() wraps a lldb.SBValue and allows you to play with your variable just
as you would expect:
pt = sbvalue.variable (lldb.frame.FindVariable("pt"))
print pt.x
print py.y
argv = sbvalue.variable (lldb.frame.FindVariable("argv"))
print argv[0]
Member access and array acccess is all taken care of!
llvm-svn: 149260
contain shared pointers to the lldb_private::Target and lldb_private::Process
objects respectively as we won't want the target or process just going away.
Also cleaned up the lldb::SBModule to remove dangerous pointer accessors.
For any code the public API files, we should always be grabbing shared
pointers to any objects for the current class, and any other classes prior
to running code with them.
llvm-svn: 149238
frames might go away (the object itself, not the actual logical frame) when
we are single stepping due to the way we currently sometimes end up flushing
frames when stepping in/out/over. They later will come back to life
represented by another object yet they have the same StackID. Now when you get
a lldb::SBFrame object, it will track the frame it is initialized with until
the thread goes away or the StackID no longer exists in the stack for the
thread it was created on. It uses a weak_ptr to both the frame and thread and
also stores the StackID. These three items allow us to determine when the
stack frame object has gone away (the weak_ptr will be NULL) and allows us to
find the correct frame again. In our test suite we had such cases where we
were just getting lucky when something like this happened:
1 - stop at breakpoint
2 - get first frame in thread where we stopped
3 - run an expression that causes the program to JIT and run code
4 - run more expressions on the frame from step 2 which was very very luckily
still around inside a shared pointer, yet, not part of the current
thread (a new stack frame object had appeared with the same stack ID and
depth).
We now avoid all such issues and properly keep up to date, or we start
returning errors when the frame doesn't exist and always responds with
invalid answers.
Also fixed the UserSettingsController (not going to rewrite this just yet)
so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to
track when the master controller has already gone away and this allowed me to
pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer
needed.
llvm-svn: 149231
all RTTI types, and since we don't use RTTI anymore since clang and llvm don't
we don't really need this header file. All shared pointer definitions have
been moved into "lldb-forward.h".
Defined std::tr1::weak_ptr definitions for all of the types that inherit from
enable_shared_from_this() in "lldb-forward.h" in preparation for thread
hardening our public API.
The first in the thread hardening check-ins. First we start with SBThread.
We have issues in our lldb::SB API right now where if you have one object
that is being used by two threads we have a race condition. Consider the
following code:
1 int
2 SBThread::SomeFunction()
3 {
4 int result = -1;
5 if (m_opaque_sp)
6 {
7 result = m_opaque_sp->DoSomething();
8 }
9 return result;
10 }
And now this happens:
Thread 1 enters any SBThread function and checks its m_opaque_sp and is about
to execute the code on line 7 but hasn't yet
Thread 2 gets to run and class sb_thread.Clear() which calls m_opaque_sp.clear()
and clears the contents of the shared pointer member
Thread 1 now crashes when it resumes.
The solution is to use std::tr1::weak_ptr. Now the SBThread class contains a
lldb::ThreadWP (weak pointer to our lldb_private::Thread class) and this
function would look like:
1 int
2 SBThread::SomeFunction()
3 {
4 int result = -1;
5 ThreadSP thread_sp(m_opaque_wp.lock());
6 if (thread_sp)
7 {
8 result = m_opaque_sp->DoSomething();
9 }
10 return result;
11 }
Now we have a solid thread safe API where we get a local copy of our thread
shared pointer from our weak_ptr and then we are guaranteed it can't go away
during our function.
So lldb::SBThread has been thread hardened, more checkins to follow shortly.
llvm-svn: 149218
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
Johnny Chen