AddCXXSummary in FormatManager::LoadSystemFormatters();
that function pulls in code that assumes python; can't
be used without the ifdef.
llvm-svn: 172300
evaluate expressions. The expression parser and
IR interpreter are now fully capable of evaluating
expressions with as much (or better) fidelity.
<rdar://problem/12879364>
llvm-svn: 172293
Providing a data formatter for libc++ std::wstring
In the process, refactoring the std::string data formatter to be written in C++ so that commonalities between the two can be exploited
Also, providing a new API on the ValueObject to navigate a hierarchy by index-path
Lastly, an appropriate test case is included
llvm-svn: 172282
Fixed an issue with the auto loading of script resources in debug info files. Any platform can add support for this, and on MacOSX we allow dSYM files to contain python modules that get automatically loaded when a dSYM file is associated with an executable or shared library.
The modifications will now:
- Let the module locate the symbol file naturally instead of using a function that only works in certain cases. This helps us to locate the script resources as long as the dSYM file can be found.
- Don't try and do any of this if the script interpreter has scripting disabled.
- Allow more than one scripting resource to be found in a symbol file by returning the list
- Load the scripting resources when a symbol file is added via the "target symbols add" command.
- Be smarter about matching the dSYM mach-o file to an existing executable in the target images by stripping extensions on the symfile basname if needed.
llvm-svn: 172275
Fixed an issue where the platform auto select code was changing the architecture and causing the wrong architecture to be assigned to the target.
llvm-svn: 172251
Also modified the Value class so that you can evaluate expressions without a process, yet with some sections loaded in the target. This allows casting pointers that are in data sections to types and being able to evaluate expressions in the data. For example:
(lldb) target create a.out
(lldb) target modules load --file a.out --slide 0
... find address of something in data ...
(lldb) script
expr_opts = lldb.SBExpressionOptions()
v = lldb.target.EvaluateExpression('(foo *)0x1230000', expr_opts)
print v
vv = lldb.value(v)
print v.pt.x
Above we were able to cast a pointer to an address which was in a.out's data
section and print out entire structures and navigate to the child ivars of the expression.
llvm-svn: 172227
Providing data formatters for char16_t* and char32_t* C++11-style Unicode strings
Using this chance to refactor the UTF data reader used for data formatters for added generality
Added a relevant test case
llvm-svn: 172119
Enabling support for the wchar_t type.
Without the proper language option setup, clang's ASTContexts will be configured to have wchar_t == int
This patch enables the correct options to make sure that we report wchar_t as itself
Added a test case to make sure we do not regress
Adding files missing from the previous commit
llvm-svn: 172039
Adding useful formatting options to the expression (expr) command.
As a side effect of this change, the -d option now supports the same three-values enumeration that frame variables uses (run, don't run, none) instead of a boolean like it did previously
These options do not apply to print, p or po because these are aliased to not take any options.
In order to use them, use expression or expr.
llvm-svn: 171993
enum
{
//----------------------------------------------------------------------
// eFlagRequiresTarget
//
// Ensures a valid target is contained in m_exe_ctx prior to executing
// the command. If a target doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidTargetDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidTargetDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresTarget = (1u << 0),
//----------------------------------------------------------------------
// eFlagRequiresProcess
//
// Ensures a valid process is contained in m_exe_ctx prior to executing
// the command. If a process doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidProcessDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidProcessDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresProcess = (1u << 1),
//----------------------------------------------------------------------
// eFlagRequiresThread
//
// Ensures a valid thread is contained in m_exe_ctx prior to executing
// the command. If a thread doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidThreadDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidThreadDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresThread = (1u << 2),
//----------------------------------------------------------------------
// eFlagRequiresFrame
//
// Ensures a valid frame is contained in m_exe_ctx prior to executing
// the command. If a frame doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidFrameDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidFrameDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresFrame = (1u << 3),
//----------------------------------------------------------------------
// eFlagRequiresRegContext
//
// Ensures a valid register context (from the selected frame if there
// is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx)
// is availble from m_exe_ctx prior to executing the command. If a
// target doesn't exist or is invalid, the command will fail and
// CommandObject::GetInvalidRegContextDescription() will be returned as
// the error. CommandObject subclasses can override the virtual function
// for GetInvalidRegContextDescription() to provide custom strings when
// needed.
//----------------------------------------------------------------------
eFlagRequiresRegContext = (1u << 4),
//----------------------------------------------------------------------
// eFlagTryTargetAPILock
//
// Attempts to acquire the target lock if a target is selected in the
// command interpreter. If the command object fails to acquire the API
// lock, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagTryTargetAPILock = (1u << 5),
//----------------------------------------------------------------------
// eFlagProcessMustBeLaunched
//
// Verifies that there is a launched process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBeLaunched = (1u << 6),
//----------------------------------------------------------------------
// eFlagProcessMustBePaused
//
// Verifies that there is a paused process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBePaused = (1u << 7)
};
Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands.
llvm-svn: 171990
last source point listed.
Also fix the setting of the default file & line to the file containing main, when you do a plain "list".
<rdar://problem/12685226>
llvm-svn: 171945
Python OS plug-ins now fetch thread registers lazily.
Also changed SBCommandInterpreter::HandleCommand() to not take the API lock. The logic here is that from the command line you can execute a command that might result in another thread (like the private process thread) to execute python or run any code that can re-enter the public API. When this happens, a deadlock immediately occurs for things like "process launch" and "process attach".
llvm-svn: 171901
Setting breakpoints using "breakpoint set --selector <SEL>" previously didn't when there was no dSYM file.
Also fixed issues in the test suite that arose after fixing the bug.
Also fixed the log channels to properly ref count the log streams using weak pointers to the streams. This fixes a test suite problem that would happen when you specified a full path to the compiler with the "--compiler" option.
llvm-svn: 171816
Have the disassembler's Instruction::Dump always insert at least
one space character between an opcode and its arguments, don't let
a long opcode name abut the arguments.
llvm-svn: 171561
- now prints the correct PYTHONPATH
- update dotest.py to use lldb -P result correctly
- resolves TestPublicAPIHeaders test failure (on Linux)
llvm-svn: 171558
Added SBTarget::EvaluateExpression() so expressions can be evaluated without needing a process.
Also fixed many functions that deal with clang AST types to be able to properly handle the clang::Type::Elaborated types ("struct foo", "class bar").
llvm-svn: 171476
migration in r171366.
I don't know anything about lldb, but a force run of the build bot indicated it
would need this patch. I'll try to watch the build bot to get it green.
llvm-svn: 171374
The results from Clang name lookups changed to
be ArrayRefs, so I had to change the way we
check for the presence of a result and the way
we iterate across results.
llvm-svn: 170927
When looking for the Python script to load for a given module, replace dots with underscores if there are any after stripping the extension
This means that for a module named foo.devel.xyz a file named foo_devel.py will be what we try to load
llvm-svn: 170633
Implement the ability for Python commands to be interrupted by pressing CTRL+C
Also add a new Mutex subclass that attempts to be helpful for debugging by logging actions performed on it
FYI of all interested - there is a separate deadlocking issue related to how LLDB dispatches CTRL+C that might cause LLDB to deadlock upon pressing CTRL+C while in a Python command.
This is not a regression, and was just previously masked by us not even trying to bail out of Python commands, so that it would not be clear from a user perspective whether we were
deadlocked or stuck in an inconsistent state within the Python interpreter.
llvm-svn: 170612
for reporting class types from Objective-C runtime
class symbols. Instead, LLDB now queries the
Objective-C runtime for class types.
We have also added a (minimal) Objective-C runtime
type vendor for Objective-C runtime version 1, to
prevent regressions when calling class methods in
the V1 runtime.
Other components of this fix include:
- We search the Objective-C runtime in a few more
places.
- We enable enumeration of all members of
Objective-C classes, which Clang does in certain
circumstances.
- SBTarget::FindFirstType and SBTarget::FindTypes
now query the Objective-C runtime as needed.
- I fixed several test cases.
<rdar://problem/12885034>
llvm-svn: 170601
Update the debugserver "qProcessInfo" implementation to return the
cpu type, cpu subtype, OS and vendor information just like qHostInfo
does so lldb can create an ArchSpec based on the returned values.
Add a new GetProcessArchitecture to GDBRemoteCommunicationClient akin
to GetHostArchitecture. If the qProcessInfo packet is supported,
GetProcessArchitecture will return the cpu type / subtype of the
process -- e.g. a 32-bit user process running on a 64-bit x86_64 Mac
system.
Have ProcessGDBRemote set the Target's architecture based on the
GetProcessArchitecture when we've completed an attach/launch/connect.
llvm-svn: 170491
Jason Molenda