This script supports displaying developer-focused backtraces when working
with mixed Java and C/C++ stack frames within lldb. On Android, this represents
just about every app, since all apps start in Java code.
The script currently supports the Art JVM when run on host-side x86_64 and x86,
but does require a patch not yet accepted in AOSP:
AOSP patch: https://android-review.googlesource.com/#/c/106523/
The backtraces will hide Art VM machinery for interpreted and AOT code
and display the Java file/line numbers for Java code, while displaying
native backtrace info for native frames. Effectively the developer will
get an app-centric view of the call stack.
This script is not yet tested on device-side Art nor is it tested on
any architecture other than x86_64 or x86 32-bit. Several changes were
needed on the AOSP side to enable it to work properly for x86_64 and x86,
so it is quite likely we'll need to do something similar for other cpu
architectures as well.
Change by Tong Shen
llvm-svn: 218315
For the Objective-C case, we do not have a "function type" notion, so we actually end up wrapping the clang ObjCMethodDecl in the Impl object, and ask function-y questions of it
In general, you can always ask for return type, number of arguments, and type of each argument using the TypeMemberFunction layer - but in the C++ case, you can also acquire a Type object for the function itself, which instead you can't do in the Objective-C case
llvm-svn: 218132
from Python. If you don't need to refer to the result in another expression, there's no
need to bloat the persistent variable table with them since you already have the result
SBValue to work with.
<rdar://problem/17963645>
llvm-svn: 215244
It was hardcoding the value "python", which will end up at best
getting a different python executable (if the user has overridden
the value of PYTHON_EXECUTABLE), and at worst encountering an
error (if there is no copy of python on the system path).
This patch changes the script to use sys.executable so that it
runs the sub-script with the same executable that it was run with.
llvm-svn: 214618
_lldb is built as an extension module on Windows. Normally to load
an extension module named 'foo', Python would look for the file
'foo.pyd'. However, when a debug interpreter is used, Python will
look for the file 'foo_d.pyd'. This change checks the build
configuration and creates the correct symlink name based on the
build configuration.
llvm-svn: 213306
This patch fixes a number of issues with embedded Python on
Windows. In particular:
1) The script that builds the python modules was normalizing the
case of python filenames during copies. The module name is
the filename, and is case-sensitive, so this was breaking code.
2) Changes the build to not attempt to link against python27.lib
(e.g. the release library) when linking against msvcrt debug
library. Doing a debug build of LLDB with embedded python
support now requires you to provide your own self-compiled
debug version of python.
3) Don't import termios when initializing the interpreter. This
is part of a larger effort to remove the dependency on termios
since it is not available on Windows. This particular instance
was unnecessary and unused.
Reviewed by: Todd Fiala
Differential Revision: http://reviews.llvm.org/D4441
llvm-svn: 212785
- Ported the SWIG wrapper shell scripts to Python so that they would work on Windows too along with other platforms
- Updated CMake handling to fix SWIG errors and manage sym-linking on Windows to liblldb.dll
- More build fixes for Windows
The pending issues are that two Python modules, termios and pexpect are not available on Windows.
These are currently required for the Python command interpreter to be used from within LLDB.
llvm-svn: 212111
Now that I'm building Linux with clang, I'm seeing more clang warnings.
This fills in some extra fields missing in the final end-of-structure-array
marker.
llvm-svn: 211812
See http://reviews.llvm.org/D4221 for details.
This commit allows you to control the signals that lldb will suppress, stop or forward using the Python and C++ APIs.
Change by Russell Harmon.
Xcode build system changes (and any mistakes) by Todd Fiala. Tested on MacOSX 10.9.3 and Xcode 6 beta. (Xcode 5 is hitting the dependency checker crasher on all my systems).
llvm-svn: 211526
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
Rationale:
Pretty simply, the idea is that sometimes type names are way too long and contain way too many details for the average developer to care about. For instance, a plain ol' vector of int might be shown as
std::__1::vector<int, std::__1::allocator<....
rather than the much simpler std::vector<int> form, which is what most developers would actually type in their code
Proposed solution:
Introduce a notion of "display name" and a corresponding API GetDisplayTypeName() to return such a crafted for visual representation type name
Obviously, the display name and the fully qualified (or "true") name are not necessarily the same - that's the whole point
LLDB could choose to pick the "display name" as its one true notion of a type name, and if somebody really needs the fully qualified version of it, let them deal with the problem
Or, LLDB could rename what it currently calls the "type name" to be the "display name", and add new APIs for the fully qualified name, making the display name the default choice
The choice that I am making here is that the type name will keep meaning the same, and people who want a type name suited for display will explicitly ask for one
It is the less risky/disruptive choice - and it should eventually make it fairly obvious when someone is asking for the wrong type
Caveats:
- for now, GetDisplayTypeName() == GetTypeName(), there is no logic to produce customized display type names yet.
- while the fully-qualified type name is still the main key to the kingdom of data formatters, if we start showing custom names to people, those should match formatters
llvm-svn: 209072
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
The FreeBSD package building cluster installs e.g. 'python2.7', but no
plain 'python' to avoid version-related issues.
CMake's FindPythonInterp locates an interpreter with such a name and
provides it in the PYTHON_EXECUTABLE variable. Use that if it's set,
falling back to the original '/usr/bin/env python' otherwise.
This is a missing part of LLDB commit r207122.
Patch by Brooks Davis in FreeBSD ports commit r353052
llvm-svn: 208204
currently associated with a given thread, on relevant targets.
Change the queue detection code to verify that the queues
associated with all live threads are included in the list.
<rdar://problem/16411314>
llvm-svn: 207160
The FreeBSD package building cluster installs e.g. 'python2.7', but no
plain 'python' to avoid version-related issues.
CMake's FindPythonInterp locates an interpreter with such a name and
provides it in the PYTHON_EXECUTABLE variable. Use that if it's set,
falling back to the original '/usr/bin/env python' otherwise.
Patch by Brooks Davis in FreeBSD ports commit r352012
llvm-svn: 207122
You can either provide the function name, or function body text.
Also propagate the compilation error up from where it is checked so we can report compilation errors.
<rdar://problem/9898371>
llvm-svn: 205380
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
changing the data it returns; this change accepts either the old format or
the new format. It doesn't yet benefit from the new format's additions -
but I need to get this checked in so we aren't rev-locked.
Also add a missing .i entry for SBQueue::GetNumRunningItems() missing from
the last checkin.
<rdar://problem/16272115>
llvm-svn: 203421
Also remove SetStopOthers from the ThreadPlanCallFunction, because if the value you have doesn't match what is
in the EvaluateExpressionOptions the plan was passed when created it won't work correctly.
llvm-svn: 202464
in lldb.svn/Makefile
* Use CPP.Flags to export the declaration. The current solution broke all builds
on http://llvm-jenkins.debian.net/
llvm-svn: 202270
Bug fix for pr18841:
http://llvm.org/bugs/show_bug.cgi?id=18841
This change creates a stub Python readline.so module that does almost
nothing. Its whole purpose is to prevent Python from loading the real
module, something it does during the embedded Python interpreter's
initialization sequence (and way before lldb ever requests it within
embedded_interpreter.py).
On Ubuntu 12.04 and 13.10 x86_64, and in the Python 2.7.6 tree, the
stock Python readline module links against the GNU readline library.
This appears to be the case on all Pythons except where __APPLE__ is
defined. LLDB now requires linking against the libedit library.
Something about having both libedit.so and libreadline.so linked into
the same process space is causing the Python readline.so to trigger a
NULL memory access. I have put in a separate patch to python.org.
This suppression of embedded interpreter readline support can be
removed if at least any one of the following happens:
1. The stock python distribution accepts a patch similar to what I
submitted to Python 2.7.6's Modules/readline.c file.
2. The stock python distribution implements Modules/readline.c in
terms of libedit's readline compatibility mode (i.e. essentially
compiles it the way __APPLE__ compiles that module) under Linux.
3. a clean-room implementation of the python readline module is
implemented against libedit (either readline compatibility mode or
native libedit). This could be implemented within the readline.cpp
file that this change introduces. It cannot be a fork of python's
readline.c module due to llvm licensing.
The net effect of this change on Linux is that the embedded python's
readline support will not exist.
llvm-svn: 202243
libldi library to collect extended backtrace information; switch
to the libBacktraceRecording library and its APIs. Complete the
work of adding QueueItems to Queues and allow for the QueueItems
to be interrogated about their extended backtraces in turn.
There's still cleanup and documentation to do on this code but the
code is functional and I it's a good time to get the work-in-progress
checked in.
<rdar://problem/15314027>
llvm-svn: 200822
PyTuple_SetItem steals a reference to the item it inserts in the tuple
This, plus the Py_XDECREF of the tuple a few lines below, causes our session dictionary to go away after the first time a SWIG layer function is called - with disastrous effects for the first subsequent attempt to use any functionality in ScriptInterpreterPython
This fixes it
llvm-svn: 200429
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
SBType SBType::GetTypedefedType();
Also added the ability to get a type by type ID from a SBModule:
SBType SBModule::GetTypeByID (lldb::user_id_t uid);
llvm-svn: 199939
"Open LLDB and run:
(lldb) script print lldb.debugger.GetInputFileHandle()
This puts the debugger into a catatonic state and all interactions seem
to enter a black hole. The reason is that executing this commnand
actually *CLOSES* the input file handle and so all input is dropped on
the floor. Oof!
The fix is simple: flush a descriptor, instead of closing it, when
transferring ownership."
llvm-svn: 198835
The "type format add" command gets a new flag --type (-t). If you pass -t <sometype>, upon fetching the value for an object of your type,
LLDB will display it as-if it was of enumeration type <sometype>
This is useful in cases of non-contiguous enums where there are empty gaps of unspecified values, and as such one cannot type their variables as the enum type,
but users would still like to see them as-if they were of the enum type (e.g. DWARF field types with their user-reserved ranges)
The SB API has also been improved to handle both types of formats, and a test case is added
llvm-svn: 198105
Todd Fiala