lldb support. I'll be doing more testing & cleanup but I wanted to
get the initial checkin done.
This adds a new SBExpressionOptions::SetLanguage API for selecting a
language of an expression.
I added adds a new SBThread::GetInfoItemByPathString for retriving
information about a thread from that thread's StructuredData.
I added a new StructuredData class for representing
key-value/array/dictionary information (e.g. JSON formatted data).
Helper functions to read JSON and create a StructuredData object,
and to print a StructuredData object in JSON format are included.
A few Cocoa / Cocoa Touch data formatters were updated by Enrico
to track changes in iOS 8 / Yosemite.
Before we query a thread's extended information, the system runtime may
provide hints to the remote debug stub that it will use to retrieve values
out of runtime structures. I added a new SystemRuntime method
AddThreadExtendedInfoPacketHints which allows the SystemRuntime to add
key-value type data to the initial request that we send to the remote stub.
The thread-format formatter string can now retrieve values out of a thread's
extended info structured data. The default thread-format string picks up
two of these - thread.info.activity.name and thread.info.trace_messages.
I added a new "jThreadExtendedInfo" packet in debugserver; I will
add documentation to the lldb-gdb-remote.txt doc soon. It accepts
JSON formatted arguments (most importantly, "thread":threadnum) and
it returns a variety of information regarding the thread to lldb
in JSON format. This JSON return is scanned into a StructuredData
object that is associated with the thread; UI layers can query the
thread's StructuredData to see if key-values are present, and if
so, show them to the user. These key-values are likely to be
specific to different targets with some commonality among many
targets. For instance, many targets will be able to advertise the
pthread_t value for a thread.
I added an initial rough cut of "thread info" command which will print
the information about a thread from the jThreadExtendedInfo result.
I need to do more work to make this format reasonably.
Han Ming added calls into the pmenergy and pmsample libraries if
debugserver is run on Mac OS X Yosemite to get information about the
inferior's power use.
I added support to debugserver for gathering the Genealogy information
about threads, if it exists, and returning it in the jThreadExtendedInfo
JSON result.
llvm-svn: 210874
the SystemRuntime to check if a thread will have any problems
performing an inferior function call so the driver can skip
making that function call on that thread. Often the function
call can be executed on another thread instead.
<rdar://problem/16777874>
llvm-svn: 208732
This is a purely mechanical change explicitly casting any parameters for printf
style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux.
llvm-svn: 205607
This is a mechanical change addressing the various sign comparison warnings that
are identified by both clang and gcc. This helps cleanup some of the warning
spew that occurs during builds.
llvm-svn: 205390
These changes were written by Greg Clayton, Jim Ingham, Jason Molenda.
It builds cleanly against TOT llvm with xcodebuild. I updated the
cmake files by visual inspection but did not try a build. I haven't
built these sources on any non-Mac platforms - I don't think this
patch adds any code that requires darwin, but please let me know if
I missed something.
In debugserver, MachProcess.cpp and MachTask.cpp were renamed to
MachProcess.mm and MachTask.mm as they picked up some new Objective-C
code needed to launch processes when running on iOS.
llvm-svn: 205113
for customizing "step-in" behavior (e.g. step-in doesn't step into code with no debug info), but also
the behavior of step-in/step-out and step-over when they step out of the frame they started in.
I also added as a proof of concept of this reworking a mode for stepping where stepping out of a frame
into a frame with no debug information will continue stepping out till it arrives at a frame that does
have debug information. This is useful when you are debugging callback based code where the callbacks
are separated from the code that initiated them by some library glue you don't care about, among other
things.
llvm-svn: 203747
hold a strong pointer to that extended backtrace thread in the Process
just like we do for asking a thread's extended backtrace.
Also, give extended backtrace threads an invalid ThreadIndexID number.
We'll still give them valid thread_id's. Clients who want to know the
original thread's IndexID can call GetExtendedBacktraceOriginatingIndexID().
<rdar://problem/16126034>
llvm-svn: 203088
The many many benefits include:
1 - Input/Output/Error streams are now handled as real streams not a push style input
2 - auto completion in python embedded interpreter
3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use
4 - it is now possible to use curses to drive LLDB (please try the "gui" command)
We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases.
llvm-svn: 200263
Added two new GDB server packets to debugserver: "QSaveRegisterState" and "QRestoreRegiterState".
"QSaveRegisterState" makes the remote GDB server save all register values and it returns a save identifier as an unsigned integer. This packet can be used prior to running expressions to save all registers.
All registers can them we later restored with "QRestoreRegiterState:SAVEID" what SAVEID is the integer identifier that was returned from the call to QSaveRegisterState.
Cleaned up redundant code in lldb_private::Thread, lldb_private::ThreadPlanCallFunction.
Moved the lldb_private::Thread::RegisterCheckpoint into its own header file and it is now in the lldb_private namespace. Trimmed down the RegisterCheckpoint class to omit stuff that wasn't used (the stack ID).
Added a few new virtual methods to lldb_private::RegisterContext that allow subclasses to efficiently save/restore register states and changed the RegisterContextGDBRemote to take advantage of these new calls.
llvm-svn: 194621
It completes the job of using EvaluateExpressionOptions consistently throughout
the inferior function calling mechanism in lldb begun in Greg's patch r194009.
It removes a handful of alternate calls into the ClangUserExpression/ClangFunction/ThreadPlanCallFunction which
were there for convenience. Using the EvaluateExpressionOptions removes the need for them.
Using that it gets the --debug option from Greg's patch to work cleanly.
It also adds another EvaluateExpressionOption to not trap exceptions when running expressions. You shouldn't
use this option unless you KNOW your expression can't throw beyond itself. This is:
<rdar://problem/15374885>
At present this is only available through the SB API's or python.
It fixes a bug where function calls would unset the ObjC & C++ exception breakpoints without checking whether
they were set by somebody else already.
llvm-svn: 194182
pure virtual base class and made StackFrame a subclass of that. As
I started to build on top of that arrangement today, I found that it
wasn't working out like I intended. Instead I'll try sticking with
the single StackFrame class -- there's too much code duplication to
make a more complicated class hierarchy sensible I think.
llvm-svn: 193983
defines a protocol that all subclasses will implement. StackFrame
is currently the only subclass and the methods that Frame vends are
nearly identical to StackFrame's old methods.
Update all callers to use Frame*/Frame& instead of pointers to
StackFrames.
This is almost entirely a mechanical change that touches a lot of
the code base so I'm committing it alone. No new functionality is
added with this patch, no new subclasses of Frame exist yet.
I'll probably need to tweak some of the separation, possibly moving
some of StackFrame's methods up in to Frame, but this is a good
starting point.
<rdar://problem/15314068>
llvm-svn: 193907
To make this work this patch extends LLDB to:
- Explicitly track the link_map address for each module. This is effectively the module handle, not sure why it wasn't already being stored off anywhere. As an extension later, it would be nice if someone were to add support for printing this as part of the modules list.
- Allow reading the per-thread data pointer via ptrace. I have added support for Linux here. I'll be happy to add support for FreeBSD once this is reviewed. OS X does not appear to have __thread variables, so maybe we don't need it there. Windows support should eventually be workable along the same lines.
- Make DWARF expressions track which module they originated from.
- Add support for the DW_OP_GNU_push_tls_address DWARF opcode, as generated by gcc and recent versions of clang. Earlier versions of clang (such as 3.2, which is default on Ubuntu right now) do not generate TLS debug info correctly so can not be supported here.
- Understand the format of the pthread DTV block. This is where it gets tricky. We have three basic options here:
1) Call "dlinfo" or "__tls_get_addr" on the inferior and ask it directly. However this won't work on core dumps, and generally speaking it's not a good idea for the debugger to call functions itself, as it has the potential to not work depending on the state of the target.
2) Use libthread_db. This is what GDB does. However this option requires having a version of libthread_db on the host cross-compiled for each potential target. This places a large burden on the user, and would make it very hard to cross-debug from Windows to Linux, for example. Trying to build a library intended exclusively for one OS on a different one is not pleasant. GDB sidesteps the problem and asks the user to figure it out.
3) Parse the DTV structure ourselves. On initial inspection this seems to be a bad option, as the DTV structure (the format used by the runtime to manage TLS data) is not in fact a kernel data structure, it is implemented entirely in useerland in libc. Therefore the layout of it's fields are version and OS dependent, and are not standardized.
However, it turns out not to be such a problem. All OSes use basically the same algorithm (a per-module lookup table) as detailed in Ulrich Drepper's TLS ELF ABI document, so we can easily write code to decode it ourselves. The only question therefore is the exact field layouts required. Happily, the implementors of libpthread expose the structure of the DTV via metadata exported as symbols from the .so itself, designed exactly for this kind of thing. So this patch simply reads that metadata in, and re-implements libthread_db's algorithm itself. We thereby get cross-platform TLS lookup without either requiring third-party libraries, while still being independent of the version of libpthread being used.
Test case included.
llvm-svn: 192922
Based on the POSIX x86_64 register context. This is sufficient for opening
a mips64 (big endian) core file. Subsequent changes will connect the
disassembler, dynamic loader support, ABI, etc.
Review: http://llvm-reviews.chandlerc.com/D1873
llvm-svn: 192335
This allows the PC to be directly changed to a different line.
It's similar to the example python script in examples/python/jump.py, except implemented as a builtin.
Also this version will track the current function correctly even if the target line resolves to multiple addresses. (e.g. debugging a templated function)
llvm-svn: 190572
Fixed a crasher when using memory threads where a thread is sticking around too long and was causing problems when it didn't have a thread plan.
llvm-svn: 187395
plan providers from a "ThreadPlan *" to a "lldb::ThreadPlanSP". That was needed to fix
a bug where the ThreadPlanStepInRange wasn't checking with its sub-plans to make sure they
succeed before trying to proceed further. If the sub-plan failed and as a result didn't make
any progress, you could end up retrying the same failing algorithm in an infinite loop.
<rdar://problem/14043602>
llvm-svn: 186618
A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error.
This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness.
llvm-svn: 186130
Jason Molenda
Saleem Abdulrasool
Jim Ingham
Deepak Panickal
Greg Clayton
Ed Maste
Richard Mitton
Matt Kopec