information about the current frame rather than
the debug information about "this" and "self"
when determining the types of those pointers.
This allows expressions to work in frames that
don't have valid "this" and "self" pointers,
working around poor debug information.
llvm-svn: 150051
sufficiently general - it could only handle
literals and operations that didn't change the
data. Now the constant evaluator passes APInt
values around, and can handle GetElementPtr
constants.
llvm-svn: 150034
the '-e' option (for watching of an address) to be present.
Update some existing test cases with the required option and add some more test cases.
Since the '-v' option takes <variable-name> and the '-e' option takes <expr> as the command arg,
the existing infrastructure for generating the option usage can produce confusing help message,
like:
watchpoint set -e [-w <watch-type>] [-x <byte-size>] <variable-name | expr>
watchpoint set -v [-w <watch-type>] [-x <byte-size>] <variable-name | expr>
The solution adopted is to provide an extra member field to the struct CommandArgumentData called
(uint32_t)arg_opt_set_association, whose purpose is to link this particular argument data with some
option set(s). Also modify the signature of CommandObject::GetFormattedCommandArguments() to:
GetFormattedCommandArguments (Stream &str, uint32_t opt_set_mask = LLDB_OPT_SET_ALL)
it now takes an additional opt_set_mask which can be used to generate a filtered formatted command
args for help message.
Options::GenerateOptionUsage() impl is modified to call the GetFormattedCommandArguments() appropriately.
So that the help message now looks like:
watchpoint set -e [-w <watch-type>] [-x <byte-size>] <expr>
watchpoint set -v [-w <watch-type>] [-x <byte-size>] <variable-name>
rdar://problem/10703256
llvm-svn: 150032
working, but not functions). I need to check on a few things to make sure
I am registering everything correctly in the right order and in the right
contexts.
llvm-svn: 149858
interface (.i) files for each class.
Changed the FindFunction class from:
uint32_t
SBTarget::FindFunctions (const char *name,
uint32_t name_type_mask,
bool append,
lldb::SBSymbolContextList& sc_list)
uint32_t
SBModule::FindFunctions (const char *name,
uint32_t name_type_mask,
bool append,
lldb::SBSymbolContextList& sc_list)
To:
lldb::SBSymbolContextList
SBTarget::FindFunctions (const char *name,
uint32_t name_type_mask = lldb::eFunctionNameTypeAny);
lldb::SBSymbolContextList
SBModule::FindFunctions (const char *name,
uint32_t name_type_mask = lldb::eFunctionNameTypeAny);
This makes the API easier to use from python. Also added the ability to
append a SBSymbolContext or a SBSymbolContextList to a SBSymbolContextList.
Exposed properties for lldb.SBSymbolContextList in python:
lldb.SBSymbolContextList.modules => list() or all lldb.SBModule objects in the list
lldb.SBSymbolContextList.compile_units => list() or all lldb.SBCompileUnits objects in the list
lldb.SBSymbolContextList.functions => list() or all lldb.SBFunction objects in the list
lldb.SBSymbolContextList.blocks => list() or all lldb.SBBlock objects in the list
lldb.SBSymbolContextList.line_entries => list() or all lldb.SBLineEntry objects in the list
lldb.SBSymbolContextList.symbols => list() or all lldb.SBSymbol objects in the list
This allows a call to the SBTarget::FindFunctions(...) and SBModule::FindFunctions(...)
and then the result can be used to extract the desired information:
sc_list = lldb.target.FindFunctions("erase")
for function in sc_list.functions:
print function
for symbol in sc_list.symbols:
print symbol
Exposed properties for the lldb.SBSymbolContext objects in python:
lldb.SBSymbolContext.module => lldb.SBModule
lldb.SBSymbolContext.compile_unit => lldb.SBCompileUnit
lldb.SBSymbolContext.function => lldb.SBFunction
lldb.SBSymbolContext.block => lldb.SBBlock
lldb.SBSymbolContext.line_entry => lldb.SBLineEntry
lldb.SBSymbolContext.symbol => lldb.SBSymbol
Exposed properties for the lldb.SBBlock objects in python:
lldb.SBBlock.parent => lldb.SBBlock for the parent block that contains
lldb.SBBlock.sibling => lldb.SBBlock for the sibling block to the current block
lldb.SBBlock.first_child => lldb.SBBlock for the first child block to the current block
lldb.SBBlock.call_site => for inline functions, return a lldb.declaration object that gives the call site file, line and column
lldb.SBBlock.name => for inline functions this is the name of the inline function that this block represents
lldb.SBBlock.inlined_block => returns the inlined function block that contains this block (might return itself if the current block is an inlined block)
lldb.SBBlock.range[int] => access the address ranges for a block by index, a list() with start and end address is returned
lldb.SBBlock.ranges => an array or all address ranges for this block
lldb.SBBlock.num_ranges => the number of address ranges for this blcok
SBFunction objects can now get the SBType and the SBBlock that represents the
top scope of the function.
SBBlock objects can now get the variable list from the current block. The value
list returned allows varaibles to be viewed prior with no process if code
wants to check the variables in a function. There are two ways to get a variable
list from a SBBlock:
lldb::SBValueList
SBBlock::GetVariables (lldb::SBFrame& frame,
bool arguments,
bool locals,
bool statics,
lldb::DynamicValueType use_dynamic);
lldb::SBValueList
SBBlock::GetVariables (lldb::SBTarget& target,
bool arguments,
bool locals,
bool statics);
When a SBFrame is used, the values returned will be locked down to the frame
and the values will be evaluated in the context of that frame.
When a SBTarget is used, global an static variables can be viewed without a
running process.
llvm-svn: 149853
Fixed "target modules list" (aliased to "image list") to output more information
by default. Modified the "target modules list" to have a few new options:
"--header" or "-h" => show the image header address
"--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library)
Removed the "--symfile-basename" or "-S" option, and repurposed it to
"--symfile-unique" "-S" which will show the symbol file if it differs from
the executable file.
ObjectFile's can now be loaded from memory for cases where we don't have the
files cached locally in an SDK or net mounted root. ObjectFileMachO can now
read mach files from memory.
Moved the section data reading code into the ObjectFile so that the object
file can get the section data from Process memory if the file is only in
memory.
lldb_private::Module can now load its object file in a target with a rigid
slide (very common operation for most dynamic linkers) by using:
bool
Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed)
lldb::SBModule() now has a new constructor in the public interface:
SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr);
This will find an appropriate ObjectFile plug-in to load an image from memory
where the object file header is at "header_addr".
llvm-svn: 149804
LLVM/Clang. This brings in several fixes, including:
- Improvements in the Just-In-Time compiler's
allocation of memory: the JIT now allocates
memory in chunks of sections, improving its
ability to generate relocations. I have
revamped the RecordingMemoryManager to reflect
these changes, as well as to get the memory
allocation and data copying out fo the
ClangExpressionParser code. Jim Grosbach wrote
the updates to the JIT on the LLVM side.
- A new ExternalASTSource interface to allow LLDB to
report accurate structure layout information to
Clang. Previously we could only report the sizes
of fields, not their offsets. This meant that if
data structures included field alignment
directives, we could not communicate the necessary
alignment to Clang and accesses to the data would
fail. Now we can (and I have update the relevant
test case). Thanks to Doug Gregor for implementing
the Clang side of this fix.
- The way Objective-C interfaces are completed by
Clang has been made consistent with RecordDecls;
with help from Doug Gregor and Greg Clayton I have
ensured that this still works.
- I have eliminated all local LLVM and Clang patches,
committing the ones that are still relevant to LLVM
and Clang as needed.
I have tested the changes extensively locally, but
please let me know if they cause any trouble for you.
llvm-svn: 149775
Changed the lldb.SBModule.section[<str>] property to return a single section.
Added a lldb.SBSection.addr property which returns an lldb.SBAddress object.
llvm-svn: 149755
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
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
All of the commands now get globbed into a single line.
lldb.target, lldb.process, lldb.thread and lldb.frame now get initialized with
empty SBTarget, SBProcess, SBThread and SBFrame objects when they don't contain
anything.
llvm-svn: 149166
will ask ExternalASTSource objects to help laying out a type. This is needed
because the DWARF typically doesn't contain alignement or packing attribute
values, and we need to be able to match up types that the compiler uses
in expressions.
llvm-svn: 149160
memory by doing a swap.
Also added a few utilty functions that can be enabled for debugging issues
with modules staying around too long when external clients still have references
to them.
llvm-svn: 149138
builds (not build and integration builds) to help catch when a shared pointer
that might be in a collection class is used after the collection
has been freed.
llvm-svn: 149136
watching for errors from pthread_mutex_destroy () (usually "Resource
busy" errors for when you have a mutex locked and try to destroy
it), and pthread_mutex_lock, and pthread_mutex_unlock (usually for
trying to lock an invalid mutex that might have possible already
been freed).
llvm-svn: 149135
ExecutionContext objects have shared pointers to Target, Process, Thread
and Frame objects and they can end up being held onto for too long.
llvm-svn: 149133
map that tracks all live Module classes. We must leak our mutex for our
collection class as it might be destroyed in an order we can't control.
llvm-svn: 149131
Remove a pseudo terminal master open and slave file descriptor that was being
used for pythong stdin. It was not hooked up correctly and was causing file
descriptor leaks.
llvm-svn: 149098
When this is imported into your lldb using the "command script import /path/to/gdbremote.py"
these new commands are available within LLDB. 'start_gdb_log' will enable logging with
timestamps for GDB remote packets, and 'stop_gdb_log' will then dump the details and
also a lot of packet timing data. This allows us to accurately track what packets are
taking up the most time when debugging (when using the ProcessGDBRemote debugging plug-in).
Also udpated the comments at the top of the cmdtemplate.py to show how to correctly import
the module from within LLDB.
llvm-svn: 149030
an error along with its boolean result. The
expression parser reports this error if the
interpreter fails and the expression could not be
run in the target.
llvm-svn: 148870
to find the possible session directories with names starting with %Y-%m-%d- (for example,
2012-01-23-) and employs the one with the latest timestamp. For example:
johnny:/Volumes/data/lldb/svn/latest/test $ ./redo.py
Using session dir path: /Volumes/data/lldb/svn/latest/test/2012-01-23-11_28_30
adding filterspec: DisassembleRawDataTestCase.test_disassemble_raw_data
Running ./dotest.py -C clang -v -t -f DisassembleRawDataTestCase.test_disassemble_raw_data
LLDB build dir: /Volumes/data/lldb/svn/latest/build/Debug
LLDB-108
Path: /Volumes/data/lldb/svn/latest
URL: https://johnny@llvm.org/svn/llvm-project/lldb/trunk
Repository Root: https://johnny@llvm.org/svn/llvm-project
Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8
Revision: 148710
Node Kind: directory
Schedule: normal
Last Changed Author: gclayton
Last Changed Rev: 148650
Last Changed Date: 2012-01-21 18:55:08 -0800 (Sat, 21 Jan 2012)
Session logs for test failures/errors/unexpected successes will go into directory '2012-01-23-17_04_48'
Command invoked: python ./dotest.py -C clang -v -t -f DisassembleRawDataTestCase.test_disassemble_raw_data
Configuration: compiler=clang
----------------------------------------------------------------------
Collected 1 test
Change dir to: /Volumes/data/lldb/svn/latest/test/python_api/disassemble-raw-data
1: test_disassemble_raw_data (TestDisassembleRawData.DisassembleRawDataTestCase)
Test disassembling raw bytes with the API. ...
Raw bytes: ['0x48', '0x89', '0xe5']
Disassembled: movq %rsp, %rbp
ok
Restore dir to: /Volumes/data/lldb/svn/latest/test
----------------------------------------------------------------------
Ran 1 test in 0.233s
OK
llvm-svn: 148766
where we changed the CommandObjectSettingsSet object impl to require raw command string.
Do the same for CommandObjectSettingsAppend/InsertBefore/InsertAfter classes and
add test cases for basic functionalities as well as for variable name completion.
llvm-svn: 148719
python so that single and double quotes and other standard shell like argument
parsing happens as expected before passing stuff along to option parsing.
Also handle exceptions so that we don't accidentally exit lldb if an uncaught
exception occurs.
llvm-svn: 148623
where we changed the CommandObjectSettingsSet object impl to require raw command string.
Do the same for CommandObjectSettingsReplace class and add two test cases; one for
the "settings replace" command and the other to ensure that completion for variable
name still works.
llvm-svn: 148615
filled out the command help and removed unused options.
Updated the command to have a "--load-all" option that will cause the target
that gets created to locate and load all images specified in the Binary Images
section of the crash log to allow for complete program state to be matched
to that of the crash log, not just the images that were in the stack frames
(the default).
llvm-svn: 148605
Fix a bug where "settings set -r th" wouldn't complete.
o UserSettingsController.cpp:
Fix a bug where "settings set target.process." wouldn't complete.
o test/functionalities/completion:
Add various completion test cases related to 'settings set' command.
llvm-svn: 148596
environment variable it set to include a path to lldb.py.
Also fixed the case where the executable can't be located and doesn't match
what is installed on the current system. It will still symbolicate the other
frames, and will just show what was originally in the crash log file.
Also removed the --crash-log option so the arguments to the "crashlog"
command are one or more paths to crash logs.
Fixed the script to "auto-install" itself when loaded from the embedded
script interpreter. Now you only need to import the module and the
command is ready for use.
llvm-svn: 148561
of the identifier name in the binary images section. Improved the regular
expression for the frames.
Added a new file "crashlog.lldb" which can be sourced with "command source"
that will import the module and set itself up to be used as a command.
llvm-svn: 148529
module (you can't import a module with a '-' in it) and also added a
Symbolcate(...) top level function so it can be imported and used as an
LLDB command.
Then you can import the module and map a "crashlog" command (for darwin
use only currently) to the python function "crashlog.Symbolicate":
(lldb) script import crashlog
(lldb) command script add -f crashlog.Symbolicate crashlog
Then use it to symbolicate:
(lldb) crashlog --crash-log /path/to/foo.crash
The crash log will then get symbolicated and inline frames will be added to
the crash log and the frames will be displayed. The crash log currently will
only try and fetch and setup the target images requires in order to do the
symbolication.
This will need to be iterated upon, but it is getting close to being useful
so I am going to check this in.
llvm-svn: 148528
to find data on the heap. To use this, make the project and then when stopped in your
lldb debug session:
(lldb) process load /path/to/libheap.dylib
(lldb) find_pointer_in_heap (0x112233000000)
This will grep everything in all active allocation blocks and print and malloc blocks that contain the pointer 0x112233000000.
This can also work for c strings:
(lldb) find_cstring_in_heap ("hello")
llvm-svn: 148523
We should ultimately introduce GetAs...Type
functions in all cases where we have Is...Type
functions that know how to look inside typedefs.
llvm-svn: 148512
http://llvm.org/viewvc/llvm-project?rev=148491&view=rev check in broke the argument completion
for "settings set th", followed by TAB. Provide a way for commands who want raw commands to
hook into the completion mechanism.
llvm-svn: 148500
Fixed an issue where backtick char is not properly honored when setting the frame-format variable, like the following:
(lldb) settings set frame-format frame #${frame.index}: ${frame.pc}{ ${module.file.basename}{`${function.name-with-args}${function.pc-offset}}}{ at ${line.file.basename}:${line.number}}\n
(lldb) settings show frame-format
frame-format (string) = "frame #${frame.index}: ${frame.pc}{ `${module.file.basename}{${function.name-with-args}${function.pc-offset}}}{` at ${line.file.basename}:${line.number}}\n"
(lldb)
o CommandObjectSettings.h/.cpp:
Modify the command object impl to require raw command string instead of parsed command string,
which also fixes an outstanding issue that customizing the prompt with trailing spaces doesn't
work.
o Args.cpp:
During CommandInterpreter::HandleCommand(), there is a PreprocessCommand phase which already
strips/processes pairs of backticks as an expression eval step. There's no need to treat
a backtick as starting a quote.
o TestAbbreviations.py and change_prompt.lldb:
Fixed incorrect test case/logic.
o TestSettings.py:
Remove expectedFailure decorator.
llvm-svn: 148491
be fetched too many times and the DisassemblerLLVM was appending to strings
when the opcode, mnemonic and comment accessors were called multiple times
and if any of the strings were empty.
Also fixed the test suite failures from recent Objective C modifications.
llvm-svn: 148460
for each ObjCInterfaceDecl was imposing performance
penalties for Objective-C apps. Instead, we now use
the normal function query mechanisms, which use the
relevant accelerator tables.
This fix also includes some modifications to the
SymbolFile which allow us to find Objective-C methods
and report their Clang Decls correctly.
llvm-svn: 148457
objective C class names when extracting the class name, selector and
name without category for objective C full class and instance method
names.
llvm-svn: 148435
where we grabbed the variable list size from the wrong list (we needed it
from "args" and we were getting it from "variable_list_sp").
llvm-svn: 148425
I've see cases where there are lingering processes ("hello_world") staying around and the
test_with_dsym_and_attach_to_process_with_name_api() test case just hangs.
llvm-svn: 148417
much smarter by extracting search results more efficiently and by properly obeying the
must_be_implementation bool in the SymbolFileDWARF::FindCompleteObjCDefinitionTypeForDIE()
function.
llvm-svn: 148413
Fixed two double "int close(int fd)" issues found by our file descriptor
interposing library on darwin:
The first is in SBDebugger::SetInputFileHandle (FILE *file, bool transfer_ownership)
where we would give our FILE * to a lldb_private::File object member variable and tell
it that it owned the file descriptor if "transfer_ownership" was true, and then we
would also give it to the communication plug-in that waits for stdin to come in and
tell it that it owned the FILE *. They would both try and close the file.
The seconds was when we use a file descriptor through ConnectionFileDescriptor
where someone else is creating a connection with ConnectionFileDescriptor and a URL
like: "fd://123". We were always taking ownwership of the fd 123, when we shouldn't
be. There is a TODO in the comments that says we should allow URL options to be passed
to be able to specify this later (something like: "fd://123?transer_ownership=1"), but
we can get to this later.
llvm-svn: 148201
master AST importer imports types.
- First, before importing the definition of a
Decl from its source, notify the underlying
importer of the source->destination mapping.
Especially for anonymous strucutres that are
otherwise hard to unique in the target AST
context, this hint is very helpful.
- When deporting a type or Decl from one
ASTContext to another (deporting occurs in
the case of moving result types from the
parser's AST context to the result AST
context), don't forget their origin if the
origin is the original debug information.
llvm-svn: 148152
debug info, call it anonymous. This isn't
perfect, because Clang actually considers the
following struct not to be anonymous:
–
struct {
int x;
int y;
} g_foo;
-
but DWARF doesn't make the distinction.
llvm-svn: 148145
Fixed the new __apple_types to be able to accept a DW_TAG_structure_type
forward declaration and then find a DW_TAG_class_type definition, or vice
versa.
llvm-svn: 148097
Need a test case that tests DWARF with .o in .a files
test/functionalities/archives:
Produces libfoo.a from a.o and b.o. Test breaking inside functions defined
inside the libfoo.a BSD Archive.
test/make/makefile.rules:
Some additional rules to sepcify archive building. For example:
ARCHIVE_NAME := libfoo.a
ARCHIVE_C_SOURCES := a.c b.c
llvm-svn: 148066
are made up from the ObjC runtime symbols. For now the latter contain nothing but the fact that the name
describes an ObjC class, and so are not useful for things like dynamic types.
llvm-svn: 148059
and doing it both at the ModuleList and Module levels means we look 4 times for a negative
search. Also, don't do the search for the stripped name if that is the same as the original
one.
llvm-svn: 148054
mmap() the entire object file contents into memory with MAP_PRIVATE.
We do this because object file contents can change on us and currently
this helps alleviate this situation. It also make the code for accessing
object file data much easier to manage and we don't end up opening the
file, reading some data and closing the file over and over.
llvm-svn: 148017
Fix DWARF parsing issue we can run into when using llvm-gcc based dSYM files.
Also fix the parsing of objective C built-in types (Class, id and SEL) so
they don't parse more information that is not needed due to the way they
are represented in DWARF.
llvm-svn: 148016
SBProcess.GetSTDERR() not getting stderr of the launched process
Since we are launch the inferior with:
process = target.LaunchSimple(None, None, os.getcwd())
i.e., without specifying stdin/out/err. A pseudo terminal is used for
handling the process I/O, and we are satisfied once the expected output
appears in process.GetSTDOUT().
llvm-svn: 147983
functions that can create file descriptors and close them. It will warn when
there close file descriptor call that returns with EBADF and show the
corresponding stack backtraces that caused the issue. It will also log all
file descriptor create and delete calls. See the comments at the top of
FDInterposing.cpp for all of the details.
llvm-svn: 147816
it was checked in as:
virtual bool ABI::FixCodeAddress (lldb::addr_t pc);
when it should have been:
virtual lldb::addr_t ABI::FixCodeAddress (lldb::addr_t pc);
llvm-svn: 147790
Fixed an ARM backtracing issue where if the previous frame was a thumb
function and it was a tail call so that the current frame returned to
an address that would fall into the next function, we would use the
next function as the basis for how we unwound the previous frame's
registers and of course get things wrong. We now fix the PC code
address using the current ABI plug-in, and the ARM ABI plug-in has
been modified to correctly fix the code address. So when we do the
symbol context lookup, instead of taking an address like 0x1001 and
decrementing 1, and looking up the symbol context for a frame, we
now correctly fix 0x1001 to 0x1000, then decrement that by 1 to
get the correct symbol context.
I added a bunch more logging to "log enable lldb uwnind" to help
us in the future. We now log the PC, FP and SP (if they are available),
and we also dump the "active_row" that we find for unwinding a frame.
llvm-svn: 147747
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
parser was creating malformed resuls. When the
location of a variable is computed by reading a
register and adding an offset, we shouldn't say
that the variable's value is located in that
register. This was confusing the expression
parser when trying to read a variable captured
by a block.
llvm-svn: 147668
performing Objective-C instance variable lookup.
Previously, it only completed the derived class
that was the beginning of the search. Now, as
it walks up the superclass chain looking for the
ivar, it completes each superclass in turn.
Also added a testcase covering this issue.
llvm-svn: 147621
This patch combines common code from Linux and FreeBSD into
a new POSIX platform. It also contains fixes for 64bit FreeBSD.
The patch is based on changes by Mark Peek <mp@FreeBSD.org> and
"K. Macy" <kmacy@freebsd.org> in their github repo located at
https://github.com/fbsd/lldb.
llvm-svn: 147613
a new POSIX platform. It also contains fixes for 64bit FreeBSD.
The patch is based on changes by Mark Peek <mp@FreeBSD.org> and
"K. Macy" <kmacy@freebsd.org> in their github repo located at
https://github.com/fbsd/lldb.
llvm-svn: 147609
so that we don't have "fprintf (stderr, ...)" calls sprinkled everywhere.
Changed all needed locations over to using this.
For non-darwin, we log to stderr only. On darwin, we log to stderr _and_
to ASL (Apple System Log facility). This will allow GUI apps to have a place
for these error and warning messages to go, and also allows the command line
apps to log directly to the terminal.
llvm-svn: 147596
result variable on a "finish" statement. The
ownership of the result value was not being properly
assigned to the newly-created persistent result
variable; now it is.
llvm-svn: 147587
Be better at detecting when DWARF changes and handle this more
gracefully than asserting and exiting.
Also fixed up a bunch of system calls that weren't properly checking
for EINTR.
llvm-svn: 147559
to include -- in sample command lines. Now LLDB
prints
expression [-f <format>] -- <expr>
instead of
expression [-f <format>] <expr>
and also adds a new example line:
expression <expr>
to show that in the absense of arguments the --
can be ommitted.
llvm-svn: 147540
eFormatCString is specified, I have made
DataExtractor::Dump properly escape the string.
This prevents LLDB from printing characters
that confuse terminals.
llvm-svn: 147536
Watch for empty symbol tables by doing a lot more error checking on
all mach-o symbol table load command values and data that is obtained.
This avoids a crash that was happening when there was no string table.
llvm-svn: 147358
Fixed an issue where our new accelerator tables could cause a crash
when we got a full 32 bit hash match, yet a C string mismatch.
We had a member variable in DWARFMappedHash::Prologue named
"min_hash_data_byte_size" the would compute the byte size of HashData
so we could skip hash data efficiently. It started out with a byte size
value of 4. When we read the table in from disk, we would clear the
atom array and read it from disk, and the byte size would still be set
to 4. We would then, as we read each atom from disk, increment this count.
So the byte size of the HashData was off, which means when we get a lookup
whose 32 bit hash does matches, but the C string does NOT match (which is
very very rare), then we try and skip the data for that hash and we would
add an incorrect offset and get off in our parsing of the hash data and
cause this crash.
To fix this I added a few safeguards:
1 - I now correctly clear the hash data size when we reset the atom array using the new DWARFMappedHash::Prologue::ClearAtoms() function.
2 - I now correctly always let the AppendAtom() calculate the byte size of the hash (before we were doing things manually some times, which was correct, but not good)
3 - I also track if the size of each HashData is a fixed byte size or not, and "do the right thing" when we need to skip the data.
4 - If we do get off in the weeds, then I make sure to return an error and stop any further parsing from happening.
llvm-svn: 147334
LLDB (python bindings) Crashing in lldb::SBDebugger::DeleteTarget(lldb::SBTarget&)
Need to check the validity of (SBTarget&)target passed to SBDebugger::DeleteTarget()
before calling target->Destroy().
llvm-svn: 147213
Jason Molenda