| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
a) adds a Python summary provider for NSDate
b) changes the initialization for ScriptInterpreter so that we are not passing a bulk of Python-specific function pointers around
c) provides a new ScriptInterpreterObject class that allows for ref-count safe wrapping of scripting objects on the C++ side
d) contains much needed performance improvements:
1) the pointer to the Python function generating a scripted summary is now cached instead of looked up every time
2) redundant memory reads in the Python ObjC runtime wrapper are eliminated
3) summaries now use the m_summary_str in ValueObject to store their data instead of passing around ( == copying) an std::string object
e) contains other minor fixes, such as adding descriptive error messages for some cases of summary generation failure
llvm-svn: 151703
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed an error where if we tried to format a ValueObject using a format
that was incorrect for a variable, then it would set ValueObject::m_error
to an error state and stop the value from being able to be updated. We now
leave m_error alone and only let the update value code change that. Any errors
in formatting will return a valid value as C string that contains an error
string. This lets us then modify the format and redisplay without any issues.
llvm-svn: 151581
|
|
|
|
| |
llvm-svn: 151535
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
more of the local path, platform path, associated symbol file, UUID, arch,
object name and object offset. This allows many of the calls that were
GetSharedModule to reduce the number of arguments that were used in a call
to these functions. It also allows a module to be created with a ModuleSpec
which allows many things to be specified prior to any accessors being called
on the Module class itself.
I was running into problems when adding support for "target symbol add"
where you can specify a stand alone debug info file after debugging has started
where I needed to specify the associated symbol file path and if I waited until
after construction, the wrong symbol file had already been located. By using
the ModuleSpec it allows us to construct a module with as little or as much
information as needed and not have to change the parameter list.
llvm-svn: 151476
|
|
|
|
|
|
|
|
|
| |
weak reference back to the Module. We were crashing when trying to make a
memory object file since it was trying to get the object in the Module
constructor before the "Module *" had been put into a shared pointer, and the
module was trying to initialize a weak pointer back to it.
llvm-svn: 151397
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I started work on being able to add symbol files after a debug session
had started with a new "target symfile add" command and quickly ran into
problems with stale Address objects in breakpoint locations that had
lldb_private::Section pointers into modules that had been removed or
replaced. This also let to grabbing stale modules from those sections.
So I needed to thread harded the Address, Section and related objects.
To do this I modified the ModuleChild class to now require a ModuleSP
on initialization so that a weak reference can created. I also changed
all places that were handing out "Section *" to have them hand out SectionSP.
All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild
so all of the find plug-in, static creation function and constructors now
require ModuleSP references instead of Module *.
Address objects now have weak references to their sections which can
safely go stale when a module gets destructed.
This checkin doesn't complete the "target symfile add" command, but it
does get us a lot clioser to being able to do such things without a high
risk of crashing or memory corruption.
llvm-svn: 151336
|
|
|
|
|
|
|
|
|
|
| |
classes.
The formatter for NSString is an improved version of the one previously shipped as an example, the others are new in design and implementation.
A more robust and OO-compliant Objective-C runtime wrapper is provided for runtime versions 1 and 2 on 32 and 64 bit.
The formatters are contained in a category named "AppKit", which is not enabled at startup.
llvm-svn: 151299
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Objective-C classes. This allows LLDB to find
ivars declared in class extensions in modules other
than where the debugger is currently stopped (we
already supported this when the debugger was
stopped in the same module as the definition).
This involved the following main changes:
- The ObjCLanguageRuntime now knows how to hunt
for the authoritative version of an Objective-C
type. It looks for the symbol indicating a
definition, and then gets the type from the
module containing that symbol.
- ValueObjects now report their type with a
potential override, and the override is set if
the type of the ValueObject is an Objective-C
class or pointer type that is defined somewhere
other than the original reported type. This
means that "frame variable" will always use the
complete type if one is available.
- The ClangASTSource now looks for the complete
type when looking for ivars. This means that
"expr" will always use the complete type if one
is available.
- I added a testcase that verifies that both
"frame variable" and "expr" work.
llvm-svn: 151214
|
|
|
|
|
|
|
|
| |
Sometimes it is not
convenient to provide a log callback right when the debugger is created.
llvm-svn: 151209
|
|
|
|
| |
llvm-svn: 151069
|
|
|
|
|
|
|
|
|
|
|
|
| |
is not available (LLDB_DISABLE_PYTHON is defined).
Change build-swig-Python.sh to emit an empty LLDBPythonWrap.cpp file if
this build is LLDB_DISABLE_PYTHON.
Change the "Copy to Xcode.app" shell script phase in the lldb.xcodeproj
to only do this copying for Mac native builds.
llvm-svn: 151035
|
|
|
|
|
|
| |
Also add SB API's to set this callback, and to enable the log channels.
llvm-svn: 151018
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
objects for the backlink to the lldb_private::Process. The issues we were
running into before was someone was holding onto a shared pointer to a
lldb_private::Thread for too long, and the lldb_private::Process parent object
would get destroyed and the lldb_private::Thread had a "Process &m_process"
member which would just treat whatever memory that used to be a Process as a
valid Process. This was mostly happening for lldb_private::StackFrame objects
that had a member like "Thread &m_thread". So this completes the internal
strong/weak changes.
Documented the ExecutionContext and ExecutionContextRef classes so that our
LLDB developers can understand when and where to use ExecutionContext and
ExecutionContextRef objects.
llvm-svn: 151009
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the lldb_private::StackFrame objects hold onto a weak pointer to the thread
object. The lldb_private::StackFrame objects the the most volatile objects
we have as when we are doing single stepping, frames can often get lost or
thrown away, only to be re-created as another object that still refers to the
same frame. We have another bug tracking that. But we need to be able to
have frames no longer be able to get the thread when they are not part of
a thread anymore, and this is the first step (this fix makes that possible
but doesn't implement it yet).
Also changed lldb_private::ExecutionContextScope to return shared pointers to
all objects in the execution context to further thread harden the internals.
llvm-svn: 150871
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
internals. The first part of this is to use a new class:
lldb_private::ExecutionContextRef
This class holds onto weak pointers to the target, process, thread and frame
and it also contains the thread ID and frame Stack ID in case the thread and
frame objects go away and come back as new objects that represent the same
logical thread/frame.
ExecutionContextRef objcets have accessors to access shared pointers for
the target, process, thread and frame which might return NULL if the backing
object is no longer available. This allows for references to persistent program
state without needing to hold a shared pointer to each object and potentially
keeping that object around for longer than it needs to be.
You can also "Lock" and ExecutionContextRef (which contains weak pointers)
object into an ExecutionContext (which contains strong, or shared pointers)
with code like
ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock());
llvm-svn: 150801
|
|
|
|
|
|
|
|
|
|
| |
categories are not enabled at startup, but can be manually activated if desired.
Adding new API calls to SBValue to be able to retrieve the associated formatters
Some refactoring to FormatNavigator::Get() in order to shrink its size down to more manageable terms (a future, massive, refactoring effort will still be needed)
Test cases added for the above
llvm-svn: 150784
|
|
|
|
|
|
|
|
|
|
| |
an unsupported byte size)
Also add a test sequence for it.
rdar://problem/10876841
llvm-svn: 150766
|
|
|
|
|
|
|
|
|
| |
DataExtractor::Dump() needs to supply the correct cursor when delegating to the child DataExtractor::Dump() calls.
Add a regression test file.
rdar://problem/10872908
llvm-svn: 150729
|
|
|
|
|
|
|
|
|
| |
class/event bit set.
Use this to allow the lldb Driver to emit notifications for breakpoint modifications.
<rdar://problem/10619974>
llvm-svn: 150665
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association.
This provides SB classes for each of the main object types involved in providing formatter support:
SBTypeCategory
SBTypeFilter
SBTypeFormat
SBTypeSummary
SBTypeSynthetic
plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions
For naming consistency, this patch also renames a lot of formatters-related classes.
Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side.
The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer.
An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes.
Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories.
llvm-svn: 150558
|
|
|
|
|
|
|
| |
for assembly instructions to occasionally come
out empty.
llvm-svn: 150445
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tracking modules down when you have a UUID and a path has been improved.
DynamicLoaderDarwinKernel no longer parses mach-o load commands and it
now uses the memory based modules now that we can load modules from memory.
Added a target setting named "target.exec-search-paths" which can be used
to supply a list of directories to use when trying to look for executables.
This allows one or more directories to be used when searching for modules
that may not exist in the SDK/PDK. The target automatically adds the directory
for the main executable to this list so this should help us in tracking down
shared libraries and other binaries.
llvm-svn: 150426
|
|
|
|
|
|
|
|
|
| |
indicate whether inline functions are desired.
This allows the expression parser, for instance,
to filter out inlined functions when looking for
functions it can call.
llvm-svn: 150279
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
user space programs. The core file support is implemented by making a process
plug-in that will dress up the threads and stack frames by using the core file
memory.
Added many default implementations for the lldb_private::Process functions so
that plug-ins like the ProcessMachCore don't need to override many many
functions only to have to return an error.
Added new virtual functions to the ObjectFile class for extracting the frozen
thread states that might be stored in object files. The default implementations
return no thread information, but any platforms that support core files that
contain frozen thread states (like mach-o) can make a module using the core
file and then extract the information. The object files can enumerate the
threads and also provide the register state for each thread. Since each object
file knows how the thread registers are stored, they are responsible for
creating a suitable register context that can be used by the core file threads.
Changed the process CreateInstace callbacks to return a shared pointer and
to also take an "const FileSpec *core_file" parameter to allow for core file
support. This will also allow for lldb_private::Process subclasses to be made
that could load crash logs. This should be possible on darwin where the crash
logs contain all of the stack frames for all of the threads, yet the crash
logs only contain the registers for the crashed thrad. It should also allow
some variables to be viewed for the thread that crashed.
llvm-svn: 150154
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 149673
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
bool
lldb_private::StateIsStoppedState (StateType state, bool must_exist)
instead.
llvm-svn: 149637
|
|
|
|
|
|
|
|
|
|
|
|
| |
'target variable' command
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
|
|
|
|
| |
llvm-svn: 149390
|
|
|
|
|
|
| |
variables, which shows YES or NO instead of the character value. A new category named objc is added to contain this summary provider. Any future Objective-C related formatters would probably fit here
llvm-svn: 149388
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
owner can notify InstanceSettings instances
that their owner reference is no longer valid.
llvm-svn: 149145
|
|
|
|
|
|
| |
test suite and I need to investigate this.
llvm-svn: 149141
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed another double file descriptor close issue that could occur when destroying a ProcessGDBRemote() object. There was a race which was detected by our fd_interposing library:
error: /Applications/Xcode.app/Contents/MacOS/Xcode (pid=55222): close (fd=60) resulted in EBADF:
0 libFDInterposing.dylib 0x00000001082be8ca close$__interposed__ + 666
1 LLDB 0x00000001194fde91 lldb_private::ConnectionFileDescriptor::Close(int&, lldb_private::Error*) + 97
2 LLDB 0x00000001194fddcd lldb_private::ConnectionFileDescriptor::Disconnect(lldb_private::Error*) + 143
3 LLDB 0x00000001194fe249 lldb_private::ConnectionFileDescriptor::Read(void*, unsigned long, unsigned int, lldb::ConnectionStatus&, lldb_private::Error*) + 835
4 LLDB 0x00000001194fc320 lldb_private::Communication::Read(void*, unsigned long, unsigned int, lldb::ConnectionStatus&, lldb_private::Error*) + 634
5 LLDB 0x000000011959c7f4 GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock(StringExtractorGDBRemote&, unsigned int) + 228
6 LLDB 0x000000011959c6b5 GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSeconds(StringExtractorGDBRemote&, unsigned int) + 49
7 LLDB 0x0000000119629a71 GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse(ProcessGDBRemote*, char const*, unsigned long, StringExtractorGDBRemote&) + 509
8 LLDB 0x00000001195a4076 ProcessGDBRemote::AsyncThread(void*) + 514
9 LLDB 0x0000000119568094 ThreadCreateTrampoline(void*) + 91
10 libsystem_c.dylib 0x00007fff8ca028bf _pthread_start + 335
11 libsystem_c.dylib 0x00007fff8ca05b75 thread_start + 13
fd=60 was previously closed with this event:
pid=55222: close (fd=60) => 0
0 libFDInterposing.dylib 0x00000001082be870 close$__interposed__ + 576
1 LLDB 0x00000001194fde91 lldb_private::ConnectionFileDescriptor::Close(int&, lldb_private::Error*) + 97
2 LLDB 0x00000001194fddcd lldb_private::ConnectionFileDescriptor::Disconnect(lldb_private::Error*) + 143
3 LLDB 0x00000001194fbf00 lldb_private::Communication::Disconnect(lldb_private::Error*) + 92
4 LLDB 0x00000001195a2a77 ProcessGDBRemote::StopAsyncThread() + 89
5 LLDB 0x00000001195a2bf6 ProcessGDBRemote::DoDestroy() + 310
6 LLDB 0x00000001195f938d lldb_private::Process::Destroy() + 85
7 LLDB 0x0000000118819b48 lldb::SBProcess::Kill() + 72
8 DebuggerLLDB 0x0000000117264358 DBGLLDBSessionThread(void*) + 4450
9 LLDB 0x0000000119568094 ThreadCreateTrampoline(void*) + 91
10 libsystem_c.dylib 0x00007fff8ca028bf _pthread_start + 335
11 libsystem_c.dylib 0x00007fff8ca05b75 thread_start + 13
fd=60 was created with this event:
pid=55222: socket (domain = 2, type = 1, protocol = 6) => fd=60
0 libFDInterposing.dylib 0x00000001082bc968 socket$__interposed__ + 600
1 LLDB 0x00000001194fd75f lldb_private::ConnectionFileDescriptor::ConnectTCP(char const*, lldb_private::Error*) + 179
.....
llvm-svn: 149103
|
|
|
|
|
|
|
|
| |
target variable -f <format> [args]
frame variable -f <format> [args]
expression -f <format> -- expr
llvm-svn: 149080
|
|
|
|
|
|
| |
A Small tweak to handle a zero timeout.
llvm-svn: 148617
|
|
|
|
|
|
|
|
|
| |
but then
we didn't implement that in setting the socket option.
<rdar://problem/10711649>
llvm-svn: 148616
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
<rdar://problem/10719481>
llvm-svn: 148494
|
|
|
|
|
|
|
|
|
| |
"${function.name-with-args}"
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
When the lldb_private::Debugger goes away, it should cleanup all
of its targets.
llvm-svn: 148189
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
name + arguments when the data is available. It seems to work really well,
but some more testing is needed before we make this on by default.
The new function format name is:
${function.name-with-args}
To see how to use these formats see the website:
http://lldb.llvm.org/formats.html
Here is a sample backtrace of debugging LLDB with LLDB using this new format
value:
(lldb) thread backtrace all
* thread #1: tid = 0x2203, 0x00007fff88a17bca libsystem_kernel.dylib __psynch_cvwait + 10, stop reason = signal SIGINT, name = <lldb.driver.main-thread>, queue = com.apple.main-thread
frame #0: 0x00007fff88a17bca libsystem_kernel.dylib __psynch_cvwait + 10
frame #1: 0x00007fff884ae274 libsystem_c.dylib _pthread_cond_wait + 840
frame #2: 0x00000001010778ea LLDB lldb_private::Condition::Wait(this=0x0000000104846770, mutex=0x0000000104846730, abstime=0x0000000000000000, timed_out=0x00007fff5fbfdea7) + 138 at Condition.cpp:92
frame #3: 0x0000000101244c21 LLDB lldb_private::Predicate<bool>::WaitForValueEqualTo(this=0x0000000104846728, value=true, abstime=0x0000000000000000, timed_out=0x00007fff5fbfdea7) + 209 at Predicate.h:317
frame #4: 0x0000000100f6eeb2 LLDB lldb_private::Listener::WaitForEventsInternal(this=0x0000000104846660, timeout=0x0000000000000000, broadcaster=0x0000000000000000, broadcaster_names=0x0000000000000000, num_broadcaster_names=0x00000000, event_type_mask=0x00000000, event_sp=0x00007fff5fbfe030) + 386 at Listener.cpp:388
frame #5: 0x0000000100f6f231 LLDB lldb_private::Listener::WaitForEvent(this=0x0000000104846660, timeout=0x0000000000000000, event_sp=0x00007fff5fbfe030) + 81 at Listener.cpp:436
frame #6: 0x0000000100098dcd LLDB lldb::SBListener::WaitForEvent(this=0x00007fff5fbff0f0, timeout_secs=0xffffffff, event=0x00007fff5fbfe430) + 685 at SBListener.cpp:181
frame #7: 0x000000010000628c lldb Driver::MainLoop(this=0x00007fff5fbff620) + 5244 at Driver.cpp:1325
frame #8: 0x0000000100006ca3 lldb main(argc=1, argv=0x00007fff5fbff758, envp=0x00007fff5fbff768) + 419 at Driver.cpp:1460
frame #9: 0x0000000100000d54 lldb start + 52
thread #3: tid = 0x2703, 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10, name = <lldb.comm.debugger.input>
frame #0: 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10
frame #1: 0x0000000100f3f072 LLDB lldb_private::ConnectionFileDescriptor::BytesAvailable(this=0x000000010524d040, timeout_usec=0x004c4b40, error_ptr=0x0000000105640a18) + 722 at ConnectionFileDescriptor.cpp:542
frame #2: 0x0000000100f3e6dd LLDB lldb_private::ConnectionFileDescriptor::Read(this=0x000000010524d040, dst=0x0000000105640a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x0000000105640a14, error_ptr=0x0000000105640a18) + 301 at ConnectionFileDescriptor.cpp:273
frame #3: 0x0000000100f3b8f7 LLDB lldb_private::Communication::ReadFromConnection(this=0x0000000104846270, dst=0x0000000105640a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x0000000105640a14, error_ptr=0x0000000105640a18) + 167 at Communication.cpp:317
frame #4: 0x0000000100f3b197 LLDB lldb_private::Communication::ReadThread(p=0x0000000104846270) + 327 at Communication.cpp:344
frame #5: 0x0000000101078923 LLDB ThreadCreateTrampoline(arg=0x00000001045f6650) + 227 at Host.cpp:549
frame #6: 0x00007fff884aa8bf libsystem_c.dylib _pthread_start + 335
frame #7: 0x00007fff884adb75 libsystem_c.dylib thread_start + 13
thread #4: tid = 0x2803, 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10, name = <lldb.comm.driver.editline>
frame #0: 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10
frame #1: 0x0000000100f3f072 LLDB lldb_private::ConnectionFileDescriptor::BytesAvailable(this=0x0000000105700370, timeout_usec=0x004c4b40, error_ptr=0x00000001056c3a18) + 722 at ConnectionFileDescriptor.cpp:542
frame #2: 0x0000000100f3e6dd LLDB lldb_private::ConnectionFileDescriptor::Read(this=0x0000000105700370, dst=0x00000001056c3a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x00000001056c3a14, error_ptr=0x00000001056c3a18) + 301 at ConnectionFileDescriptor.cpp:273
frame #3: 0x0000000100f3b8f7 LLDB lldb_private::Communication::ReadFromConnection(this=0x0000000105700000, dst=0x00000001056c3a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x00000001056c3a14, error_ptr=0x00000001056c3a18) + 167 at Communication.cpp:317
frame #4: 0x0000000100f3b197 LLDB lldb_private::Communication::ReadThread(p=0x0000000105700000) + 327 at Communication.cpp:344
frame #5: 0x0000000101078923 LLDB ThreadCreateTrampoline(arg=0x0000000105700430) + 227 at Host.cpp:549
frame #6: 0x00007fff884aa8bf libsystem_c.dylib _pthread_start + 335
frame #7: 0x00007fff884adb75 libsystem_c.dylib thread_start + 13
thread #5: tid = 0x2903, 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10, name = <lldb.comm.driver.editline_output>
frame #0: 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10
frame #1: 0x0000000100f3f072 LLDB lldb_private::ConnectionFileDescriptor::BytesAvailable(this=0x00000001057178f0, timeout_usec=0x004c4b40, error_ptr=0x0000000105980a18) + 722 at ConnectionFileDescriptor.cpp:542
frame #2: 0x0000000100f3e6dd LLDB lldb_private::ConnectionFileDescriptor::Read(this=0x00000001057178f0, dst=0x0000000105980a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x0000000105980a14, error_ptr=0x0000000105980a18) + 301 at ConnectionFileDescriptor.cpp:273
frame #3: 0x0000000100f3b8f7 LLDB lldb_private::Communication::ReadFromConnection(this=0x0000000105717580, dst=0x0000000105980a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x0000000105980a14, error_ptr=0x0000000105980a18) + 167 at Communication.cpp:317
frame #4: 0x0000000100f3b197 LLDB lldb_private::Communication::ReadThread(p=0x0000000105717580) + 327 at Communication.cpp:344
frame #5: 0x0000000101078923 LLDB ThreadCreateTrampoline(arg=0x00000001057179b0) + 227 at Host.cpp:549
frame #6: 0x00007fff884aa8bf libsystem_c.dylib _pthread_start + 335
frame #7: 0x00007fff884adb75 libsystem_c.dylib thread_start + 13
thread #6: tid = 0x2a03, 0x00007fff88a18af2 libsystem_kernel.dylib read + 10, name = <lldb.driver.commandline_io>
frame #0: 0x00007fff88a18af2 libsystem_kernel.dylib read + 10
frame #1: 0x0000000100050c3b libedit.3.dylib read_init + 247
frame #2: 0x0000000100050e96 libedit.3.dylib el_wgetc + 155
frame #3: 0x000000010005115d libedit.3.dylib el_wgets + 578
frame #4: 0x000000010005debc libedit.3.dylib el_gets + 37
frame #5: 0x000000010000d409 lldb IOChannel::LibeditGetInput(this=0x0000000105700490, new_line=0x0000000105a03db0) + 89 at IOChannel.cpp:311
frame #6: 0x000000010000d8b6 lldb IOChannel::Run(this=0x0000000105700490) + 806 at IOChannel.cpp:391
frame #7: 0x000000010000d57d lldb IOChannel::IOReadThread(ptr=0x0000000105700490) + 29 at IOChannel.cpp:345
frame #8: 0x0000000101078923 LLDB ThreadCreateTrampoline(arg=0x00000001057179f0) + 227 at Host.cpp:549
frame #9: 0x00007fff884aa8bf libsystem_c.dylib _pthread_start + 335
frame #10: 0x00007fff884adb75 libsystem_c.dylib thread_start + 13
(lldb)
llvm-svn: 148110
|
|
|
|
| |
llvm-svn: 148057
|