thread before UnwindLLDB::AddOneMoreFrame calls it quits. We have
a couple of reports of unending backtraces in the field and we
haven't been able to collect any information about what kind of
backtrace is causing this. We've found on Mac OS X that it's tricky
to get more than around 200k stack frames before a process exceeds
its stack space so we're starting with a hard limit of 300,000 frames.
<rdar://problem/13383069>
llvm-svn: 180995
SWIG is smart enough to recognize that C++ operators == and != mean __eq__ and __ne__ in Python and do the appropriate translation
But it is not smart enough to recognize that mySBObject == None should return False instead of erroring out
The %pythoncode blocks are meant to provide those extra smarts (and they play some SWIG&Python magic to find the right function to call behind the scenes with no risk of typos :-)
Lastly, SBBreakpoint provides an == but never provided a != operator - common courtesy is to provide both
llvm-svn: 180987
Allow command script import to load packages.
e.g.:
egranata$ ./lldb
(lldb) command script import lldb.macosx.crashlog
"crashlog" and "save_crashlog" command installed, use the "--help" option for detailed help
"malloc_info", "ptr_refs", "cstr_refs", and "objc_refs" commands have been installed, use the "--help" options on these commands for detailed help.
The "unwind-diagnose" command has been installed, type "help unwind-diagnose" for detailed help.
(lldb)
./lldb
(lldb) command script import theFoo
I am happy
(lldb) fbc
àèìòù
(lldb)
egranata$ ls theFoo/
__init__.py theBar.py
egranata$ cat theFoo/__init__.py
import lldb
import theBar
def __lldb_init_module(debugger, internal_dict):
print "I am happy"
debugger.HandleCommand("command script add -f theFoo.theBar.theCommand fbc")
return None
egranata$ cat theFoo/theBar.py
#encoding=utf-8
def theCommand(debugger, command, result, internal_dict):
result.PutCString(u"àèìòù")
return None
llvm-svn: 180975
DynamicLoaderDarwinKernel finds in memory, have DynamicLoaderDarwinKernel
re-set the Target's arch based on the kernel's cpu type / cpu subtype.
llvm-svn: 180962
clang sugarcoats expressions of the sort *(int (*)[3])foo where foo is an int* saying that their type class is Paren
This checkin updates our lookup tables to properly desugar Paren into the actual type of interest
llvm-svn: 180938
support operands with vector types, it now reports
that it cannot interpret expressions that use
vector types. They get sent to the JIT instead.
<rdar://problem/13733651>
llvm-svn: 180899
in debug information more aggressive. Emitting
classes containing these methods causes crashes in
Clang when dealing with complex code bases.
<rdar://problem/12640887>
llvm-svn: 180895
<rdar://problem/13723772>
Modified the lldb_private::Thread to work much better with the OperatingSystem plug-ins. Operating system plug-ins can now return have a "core" key/value pair in each thread dictionary for the OperatingSystemPython plug-ins which allows the core threads to be contained with memory threads. It also allows these memory threads to be stepped, resumed, and controlled just as if they were the actual backing threads themselves.
A few things are introduced:
- lldb_private::Thread now has a GetProtocolID() method which returns the thread protocol ID for a given thread. The protocol ID (Thread::GetProtocolID()) is usually the same as the thread id (Thread::GetID()), but it can differ when a memory thread has its own id, but is backed by an actual API thread.
- Cleaned up the Thread::WillResume() code to do the mandatory parts in Thread::ShouldResume(), and let the thread subclasses override the Thread::WillResume() which is now just a notification.
- Cleaned up ClearStackFrames() implementations so that fewer thread subclasses needed to override them
- Changed the POSIXThread class a bit since it overrode Thread::WillResume(). It is doing the wrong thing by calling "Thread::SetResumeState()" on its own, this shouldn't be done by thread subclasses, but the current code might rely on it so I left it in with a TODO comment with an explanation.
llvm-svn: 180886
- Required for platform-independant handling of general purpose registers (i.e. for core dumps).
Thanks to Samuel Jacob for this patch.
llvm-svn: 180878
AppendMessage("") is called. This idiom is used in a handful of places
right now (e.g. to put space between different threads in 'bt all') but
the empty newline is being omitted instead of emitted.
<rdar://problem/13753830>
llvm-svn: 180841
UInts even if their contents were set as bytes.
This makes expressions using registers work
better, especially with core files.
<rdar://problem/13743427>
llvm-svn: 180810
Enabling LLDB to write to variables that are stored in registers
Previously, this would not work since the Value's Context loses the notion of the data being in a register
We now store an "original" context that comes out of DWARF parsing, and use that context's data when attempting a write
llvm-svn: 180803
std::string
Module::GetSpecificationDescription () const;
This returns the module as "/usr/lib/libfoo.dylib" for normal files (calls "std::string FileSpec::GetPath()" on m_file) but it also might include the object name in case the module is for a .o file in a BSD archive ("/usr/lib/libfoo.a(bar.o)"). Cleaned up necessary logging code to use it.
llvm-svn: 180717
print the disassembly context around $pc -- just print the filename and line number, even if we
can't show the source code. Previously if the source file was not available, lldb would print
the source filename & line number and assembly.
<rdar://problem/13072951>
llvm-svn: 180706
will run xcode-select --print-path to find the currently selected
Xcode developer directory. Mostly useful for when lldb is not being run out
of the /Applications/Xcode.app bundle so it can't locate the iOS or
kernel SDKs.
llvm-svn: 180705
with directories, without increasing the size of the FileSpec object.
GetPath() returns a std::string of the full pathname of the file.
IsDirectory(), IsPipe(), IsRegularFile(), IsSocket(), and IsSymbolicLink()
can be used instead of getting the FileType() and comparing it to an enum.
Update PlatformDarwinKernel to use these new methods.
llvm-svn: 180704
mostly related to management of the stack frame
for the interpreter.
- First, if the expression can be interpreted,
allocate the stack frame in the target process
(to make sure pointers are valid) but only
read/write to the copy in the host's memory.
- Second, keep the memory allocations for the
stack frame and the materialized struct as
member variables of ClangUserExpression. This
avoids memory allocations and deallocations
each time the expression runs.
<rdar://problem/13043685>
llvm-svn: 180664
- Adds unique enums for ymm registers to the ABI and the POSIX register context.
- Reworks the register context data structures to support a union of FXSAVE and XSAVE
--- Allows the same code base to deal with the FPU independent of the availability of AVX.
- Determine if AVX is supported by attempting to read XSAVE using ptrace.
--- Support an extended register set for avx registers if available.
- Provide a mechanism to assemble/parse register halves into a single ymm buffer for use with RegisterValue.
--- Reworked Read/WriteRegister routines to read/write/parse ymm registers.
Adds tests for ymm register write with read-back, and expressions involving ymm registers.
- Tests vary depending on the availability of an avx register set.
Thanks to Daniel and Matt for their reviews.
llvm-svn: 180572
interpreter. They are a legacy from when the IR
interpreter didn't work with materialized values
but rather got values directly from
ClangExpressionDeclMap.
Also updated the #includes for IRInterpreter
accordingly.
llvm-svn: 180565
specially, and make sure we stop. This shouldn't happen, but if it does, the user will probably want to
see it.
<rdar://problem/13273125>
llvm-svn: 180244
There is a new static ObjectFile function you can call:
size_t
ObjectFile::GetModuleSpecifications (const FileSpec &file,
lldb::offset_t file_offset,
ModuleSpecList &specs)
This will fill in "specs" which the details of all the module specs (file + arch + UUID (if there is one) + object name (for BSD archive objects eventually) + file offset to the object in question).
This helps us when a user specifies a file that contains a single architecture, and also helps us when we are given a debug symbol file (like a dSYM file on MacOSX) that contains one or more architectures and we need to be able to match it up to an existing Module that has no debug info.
llvm-svn: 180224
The user was trying to obtain the address-of an std::vector and the experience was more painful than necessary because data formatters were kicking in for vector* objects
We got this right for libc++ - we should get it right for libstdc++ too
llvm-svn: 180219
(normally undefined) as indicating a breakpoint hit, in addition
to the normal (EXC_BREAKPOINT, EXC_ARM_BREAKPOINT) pair.
<rdar://problem/13730366>
llvm-svn: 180216
out of the runtime. This allows calling static methods
on classes whose symbols have been stripped out of the
binary.
<rdar://problem/12042992>
llvm-svn: 180210
not find multiple functions with the same name but
different types. Now we keep track of what types
we've already reported for a function and only elide
functions if we've already reported a conflicting
one.
Also added a test case.
<rdar://problem/11367837>
llvm-svn: 180167
Fixed LLDB to be able to correctly parse template parameters that have no name and no type. This can be triggered by the following LLVM/Clang code:
template <typename T, typename = void>
class SmallVectorTemplateCommon : public SmallVectorBase {
The “typename = void” was emitting DWARF with an empty DW_AT_name and no DW_AT_type. We now correctly infer that no DW_AT_type means “void” and that an empty name is ok.
This means you can now call functions on things that inherit from SmallVectorTemplateCommon.
llvm-svn: 180155
This checkin reverts NSString to the old behavior when appropriate, and cleans up the syntax to call the UTF Reader&Dumper function
Incidentally, add a "-d" command-line flag to redo.py with the same semantics as "-d" in dotest.py
llvm-svn: 180141
Patch by Yacine Belkadi!
When __GLIBC__ is defined, optind gets initialized to 0. So for the first parsed
option, parse_start is 0, too. If this option has no argument (Like "--continue"
of "process attach"), then the position stored is 0, instead of 1. This prevents
the completion later on in Options::HandleOptionCompletion() because the opt_pos
doesn't match the cursor_index.
Fix that by getting the option's position from the value of optind, as it's done
for the other types of options.
Re-enable test_process_attach_dash_dash_con() on Linux.
No regressions detected on Mac OS X (in TestCompletion.py)
llvm-svn: 180114
unwind instructions for a function/symbol which contains that
address.
Update the unwind_diagnose.py script to use this instead of doing
image show-unwind by name to avoid cases where there are multiple
name definitions.
llvm-svn: 180079
Providing a dummy RegisterContext to secure against faulty Python OS plugins that do not return a valid RegisterContext
The RegisterContextDummy exports a PC with a constant 0xFFFFFFFFFFFFFFFF value
llvm-svn: 180033
and persistent variables so that they are not
treated as remaining in the target process (i.e.,
having live data) when the process does not allow
persistent allocations (e.g., when there is no
process or in the case of kernel core files).
llvm-svn: 179919
Fixed the GDB remote with the python OS plug-in to not show core threads when they aren't desired and also to have the threads "to the right thing" when continuing.
llvm-svn: 179912
realpathing the executable binary if we fail to find a
binary and if it starts with a ~ character, based on feedback
from Greg Clayton.
llvm-svn: 179904
variables in the ValueObject code:
- Report an error if the variable does not have
a valid address.
- Return the contents of the data to GetData(),
even if the value is constant.
<rdar://problem/13690855>
llvm-svn: 179876
This prevents unbounded reads (i.e. reads of GetMaximumSizeOfStringSummary() bytes)
from causing test failures (i.e. due to ptrace EIO or EFAULT on Linux).
Note that ReadCStringFromMemory is marked as deprecated because the loop that calls
ReadMemory does not continue until the string has been completely read.
The expected behavior is to read until until max_bytes or a null terminator.
Note: As discussed on lldb-dev, further testing will be performed with ReadStringFromMemory
before further changes are made for users of ReadCStringFromMemory.
Thanks to Enrico, Matt and Andy for their review feedback.
llvm-svn: 179857
Previously, the options for a breakopint or its
locations stored only the text of the breakpoint
condition (ironically, they used ClangUserExpression
as a glorified std::string) and, each time the condition
had to be evaluated in the StopInfo code, the expression
parser would be invoked via a static method to parse and
then execute the expression.
I made several changes here:
- Each breakpoint location now has its own
ClangUserExpressionSP containing a version of
the breakpoint expression compiled for that exact
location.
- Whenever the breakpoint is hit, the breakpoint
condition expression is simply re-run to determine
whether to stop.
- If the process changes (e.g., it's re-run) or
the source code of the expression changes (we use
a hash so as to avoid doing string comparisons)
the ClangUserExpressionSP is re-generated.
This should improve performance of breakpoint
conditions significantly, and takes advantage of
the recent expression re-use work.
llvm-svn: 179838
and made attempts to allocate memory in the process
fall back to FindSpace and just allocate memory on
the host (but with real-looking pointers, hence
FindSpace) if the process doesn't allow allocation.
This allows expressions to run on processes that don't
support allocation, like core files.
This introduces an extremely rare potential problem:
If all of the following are true:
- The Process doesn't support allocation;
- the user writes an expression that refers to an
address that does not yet map to anything, or is
dynamically generated (e.g., the result of calling
a function); and
- the randomly-selected address for the static data
for that specific expression runs into the
address the user was expecting to work with;
then dereferencing the pointer later results
in the user seeing something unexpected. This is
unlikely but possible; as a future piece of work,
we should have processes be able to hint to the
expression parser where it can allocate temporary data
of this kind.
llvm-svn: 179827
expressions.
Previously, ClangUserExpression assumed that if
there was a constant result for an expression
then it could be determined during parsing. In
particular, the IRInterpreter ran while parser
state (in particular, ClangExpressionDeclMap)
was present. This approach is flawed, because
the IRInterpreter actually is capable of using
external variables, and hence the result might
be different each run. Until now, we papered
over this flaw by re-parsing the expression each
time we ran it.
I have rewritten the IRInterpreter to be
completely independent of the ClangExpressionDeclMap.
Instead of special-casing external variable lookup,
which ties the IRInterpreter closely to LLDB,
we now interpret the exact same IR that the JIT
would see. This IR assumes that materialization
has occurred; hence the recent implementation of the
Materializer, which does not require parser state
(in the form of ClangExpressionDeclMap) to be
present.
Materialization, interpretation, and dematerialization
are now all independent of parsing. This means that
in theory we can parse expressions once and run them
many times. I have three outstanding tasks before
shutting this down:
- First, I will ensure that all of this works with
core files. Core files have a Process but do not
allow allocating memory, which currently confuses
materialization.
- Second, I will make expression breakpoint
conditions remember their ClangUserExpression and
re-use it.
- Third, I will tear out all the redundant code
(for example, materialization logic in
ClangExpressionDeclMap) that is no longer used.
While implementing this fix, I also found a bug in
IRForTarget's handling of floating-point constants.
This should be fixed.
llvm-svn: 179801
- Specify SC_Static given DIE attributes for static methods and operators.
Thanks to Wei Pan for his review and the help with root-causing.
llvm-svn: 179727
will be gone soon!) that lets it interpret a function
using just an llvm::Module, an llvm::Function, and a
MemoryMap.
Also added an API to IRExecutionUnit to get at its
llvm::Function, so that the IRInterpreter can work
with it.
llvm-svn: 179704
a ClangExpressionDeclMap. Any functions that
require value resolution etc. fail if the
ClangExpressionDeclMap isn't present - which is
exactly what is desired.
llvm-svn: 179695
- conditionally build mac-specific plugins only on mac (PluginObjectFileMachO, PluginDynamicLoaderDrawinKernel and PluginDynamicLoaderMacOSXDYLD)
- clean up warnings by ignoring deprecated declarations (auto_ptr for example)
llvm-svn: 179694
IRMemoryMap rather than through its own memory
abstraction. This considerably simplifies the
code, and makes it possible to run the
IRInterpreter multiple times on an already-parsed
expression in the absence of a ClangExpressionDeclMap.
Changes include:
- ClangExpressionDeclMap's interface methods
for the IRInterpreter now take IRMemoryMap
arguments. They are not long for this world,
however, since the IRInterpreter will soon be
working with materialized variables.
- As mentioned above, removed the Memory class
from the IR interpreter altogether. It had a
few functions that remain useful, such as
keeping track of Values that have been placed
in memory, so I moved those into methods on
InterpreterStackFrame.
- Changed IRInterpreter to work with lldb::addr_t
rather than Memory::Region as its primary
currency.
- Fixed a bug in the IRMemoryMap where it did not
report correct address byte size and byte order
if no process was present, because it was using
Target::GetDefaultArchitecture() rather than
Target::GetArchitecture().
- Made IRMemoryMap methods clear the Errors they
receive before running. Having to do this by
hand is just annoying.
The testsuite seems happy with these changes, but
please let me know if you see problems (especially
in use cases without a process).
llvm-svn: 179675
Materializer for all expressions that need to
run in the target. This includes the following
changes:
- Removed a bunch of (de-)materialization code
from ClangExpressionDeclMap and assumed the
presence of a Materializer where we previously
had a fallback.
- Ensured that an IRMemoryMap is passed into
ClangExpressionDeclMap::Materialize().
- Fixed object ownership on LLVMContext; it is
now owned by the IRExecutionUnit, since the
Module and the ExecutionEngine both depend on
its existence.
- Fixed a few bugs in IRMemoryMap and the
Materializer that showed up during testing.
llvm-svn: 179649
ShouldStop on the threads, which might destroy information needed to correctly compute another
thread's StopInfo.
<rdar://problem/13664026>
llvm-svn: 179641
differs from lldb's own shared cache, and where the inferior process shared
cache does not match up with the on-disk shared cache file.
Simplify the code where lldb gets its own shared cache uuid a little bit.
llvm-svn: 179633
Show an error message when we have a corrupt mach-o file where the LC_SEGMENT or LC_SEGMENT_64 load command have file offsets or file offsets + sizes that extend beyond the end of the file.
llvm-svn: 179605
a UUID for the shared cache libraries that can be used to confirm
that one process' shared cache is the same as another, or that a
process' in-memory shared cache is a match for a given on-disk
dyld_shared_cache binary file. Use these UUIDs to catch some
uncommon problems when the shared caches are being changed for debug
purposes.
<rdar://problem/13524467>
llvm-svn: 179583
- If an allocation is mirrored between the host
and the process, update the host's version
before returning a DataExtractor pointing to
it.
- If anyone attempts to access memory in a
process/target that does not have a corresponding
allocation, try accessing the memory directly
before erroring out.
llvm-svn: 179561
- Do not add symbols with no names
- Make sure that symbols from ELF symbol tables know that the byte size is correct. Previously the symbols would calculate their sizes by looking for the next symbol and take symbols that had zero size and make them have invalid sizes.
- Added the ability to dump raw ELF symbols by adding a Dump method to ELFSymbol
Also removed some unused code from lldb_private::Symtab.
llvm-svn: 179466
lets a ValueObject's contents be set from raw
data. This has certain limitations (notably,
registers can only be set to data that is as
large as the register) but will be useful for
the new Materializer.
I also exposed this interface through SBValue.
I have added a testcase that exercises various
special cases of SBValue::SetData().
llvm-svn: 179437
Ashok Thirumurthi