- 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
defines a Return Address register (e.g. lr on arm) but the RA register
hasn't been saved anywhere yet -- it is still in a live reg.
<rdar://problem/13503130>
llvm-svn: 179431
for variables in the new Materializer. This is
much easier now that the ValueObject API is solid.
I still have to implement reading bytes into a
ValueObject, but committing what I have so far.
This code is not yet used, so there will be fixes
when I switch the expression parser over to use the
new Materializer.
llvm-svn: 179416
Made some fixes to the OperatingSystemPython class:
- If any thread dictionary contains any "core=N" key/value pairs then the threads obtained from the lldb_private::Process itself will be placed inside the ThreadMemory threads and will be used to get the information for a thread.
- Cleaned up all the places where a thread inside a thread was causing problems
llvm-svn: 179405
could delete the other locations, and that would leave us iterating over a reduced size collection and crash.
<rdar://problem/13592544>
llvm-svn: 179332
This patch fixes the issue that we were using the C stack as a measure of depth of ValueObject hierarchies, in the sense that we were assuming that recursive ValueObject operations would never be deeper than the stack allows.
This assumption is easy to prove wrong, however.
For instance, after ~10k runs through this loop:
struct node
{
int value;
node* child;
node (int x)
{
value = x;
child = nullptr;
}
};
int main ()
{
node root(1);
node* ptr = &root;
int j = 2;
while (1)
{
ptr->child = new node(j++);
ptr = ptr->child;
}
return 0;
}
the deepmost child object will be deeper than the stack on most architectures, and we would be unable to display it
This checkin fixes the issue by introducing a notion of root of ValueObject hierarchies.
In a couple cases, we have to use an iterative algorithm instead of going to the root because we want to allow deeper customizations (e.g. formats, dynamic values).
While the patch passes our test suite without regressions, it is a good idea to keep eyes open for any unexpected behavior (recursion can be subtle..)
Also, I am hesitant to introduce a test case since failing at this will not just be marked as an "F", but most definitely crash LLDB.
llvm-svn: 179330
Fixed a case there the OperatingSystemPython would try to access and play with SBValue objects when the process' public run lock was taken. Prior to this fix, all attempts to run any SBValue functions would fail if run from the private state thread (like updating the thread list). Now we have two run locks, one for public (all threads except the private state thread) and one for private.
llvm-svn: 179329
to the Materializer. Materialization is still done by
the ClangExpressionDeclMap; this will be the next thing
to move.
Also fixed a layout bug that this uncovered.
llvm-svn: 179318
to '-A'.
Add option '-a' / '--address' to disassemble which will find the
function that contains that address, and disassemble the entire function.
<rdar://problem/13436207>
llvm-svn: 179258
information about each variable that needs to
be materialized for an expression to work. The
next step is to migrate all materialization code
from ClangExpressionDeclMap to Materializer, and
to use it for variable materialization.
llvm-svn: 179245
SectionList so we don't try to do anything with this file. Currently we end up crashing
later in the debug session when we read past the end of the file -- this at least gets us
closer with something like ProcessMachCore printing "error: core file has no sections".
<rdar://problem/13468295>
llvm-svn: 179152
if we didn't want to put in a CXXConstructorDecl. This
prevents malformed classes (i.e., classes with regular C
functions as members) from being generated from type
information (and fixes a crash in the test suite).
<rdar://problem/13550765>
llvm-svn: 179136
Now we can:
1 - see the return value for functions that return types that use the "ext_vector_size"
2 - dump values that use the vector attributes ("expr $ymm0")
3 - modified the DWARF parser to correctly parse GNU vector types from the DWARF by turning them into clang::Type::ExtVector types instead of just standard arrays
llvm-svn: 178924
platform.plugin.darwin-kernel.kext-directories
platform.plugin.darwin-kernel.search-locally-for-kexts
and fix a few FileSpec handling issues for the kext-directories setting.
llvm-svn: 178920
Introducing a negative cache for ObjCLanguageRuntime::LookupInCompleteClassCache()
This helps speed up the (common) case of us looking for classes that are hidden deep within Cocoa internals and repeatedly failing at finding type information for them.
In order for this to work, we need to clean this cache whenever debug information is added. A new symbols loaded event is added that is triggered with add-dsym (before modules loaded would be triggered for both adding modules and adding symbols).
Interested parties can register for this event. Internally, we make sure to clean the negative cache whenever symbols are added.
Lastly, ClassDescriptor::IsTagged() has been refactored to GetTaggedPointerInfo() that also (optionally) returns info and value bits. In this way, data formatters can share tagged pointer code instead of duplicating the required arithmetic.
llvm-svn: 178897
Add two initial settings for the PlatformDarwinKernel plugin,
plugin.platform.darwin-kernel.search-locally-for-kexts [true|false]
plugin.platform.darwin-kernel.kext-directories [directory list]
llvm-svn: 178846
from the current Target, if there is one, else back off to getting
the currently selected platform from the Debugger (as it ws doing
previously.)
Remove code from DynamicLoaderDarwinKernel that was setting the platform
in both the Target and in the Debugger.
llvm-svn: 178836
from IRExecutionUnit into a superclass called
IRMemoryMap. IRMemoryMap handles all reading and
writing, ensuring that areas are kept track of and
memory is properly cached (and deleted).
Also fixed several cases where we would simply leak
binary data in the target process over time. Now
the expression objects explicitly own their
IRExecutionUnit and delete it when they go away. This
is why I had to modify ClangUserExpression,
ClangUtilityFunction, and ClangFunction.
As a side effect of this, I am removing the JIT
mutex for an IRMemoryMap. If it turns out that we
need this mutex, I'll add it in then, but right now
it's just adding complexity.
This is part of a more general project to make
expressions fully reusable. The next step is to
make materialization and dematerialization use
the IRMemoryMap API rather than writing and
reading directly from the process's memory.
This will allow the IR interpreter to use the
same data, but in the host's memory, without having
to use a different set of pointers.
llvm-svn: 178832
plugin will index the kext bundles on the local filesystem when
created. During a kernel debug session, when the DynamicLoader
plugin needs to locate a kext by name like
"com.apple.com.apple.filesystems.autofs", the Platform can quickly
look for a UUID match in those kernel debug kit directories it
previously indexed.
I'm still working on profiling the performance impact of the inital
kext bundle scan; there will likely need to be a switch to enable
or disable this plugin's scan.
This only affects Mac kernel debugging and the code is only built
on Apple systems because of some use of low-level CoreFoundation
to parse plists.
<rdar://problem/13503583>
llvm-svn: 178827
LLDB now can use a single dash for all long options for all commands form the command line and from the command interpreter. This involved just switching all calls from getopt_long() to getopt_long_only().
llvm-svn: 178789
The __NSArrayI synthetic children provider was running expressions to generate children, which is inefficient for large amounts of data
Reimplementing to use a faster algorithm
llvm-svn: 178729
Changes to lldb made the following fail when it used to work:
% cd /tmp
% lldb ls
error: unable to find executable for '/tmp/ls'
Resolving an executable with no relative path was broken, now its fixed.
llvm-svn: 178719
Make lldb_private::RegularExpression thread safe everywhere. This was done by removing the m_matches array from the lldb_private::RegularExpression class and putting it into the new lldb_private::RegularExpression::Match class. When executing a regular expression you now have the option to create a lldb_private::RegularExpression::Match object and pass a pointer in if you want to get parenthesized matching. If you don't want any matching, you pass in NULL. The lldb_private::RegularExpression::Match object is initialized with the number of matches you desire. Any matching strings are now extracted from the lldb_private::RegularExpression::Match objects. This makes the regular expression objects thread safe and as a result many more regex objects were turned into static objects that end up using a local lldb_private::RegularExpression::Match object when executing.
llvm-svn: 178702
Symbol table function names should support lookups like symbols with debug info.
To fix this I:
- Gutted the way FindFunctions is used, there used to be way too much smarts only in the DWARF plug-in
- Made it more efficient by chopping the name up once and using simpler queries so that SymbolFile and Symtab plug-ins don't need to do as much
- Filter the results at a higher level
- Make the lldb_private::Symtab able to chop up C++ mangled names and make as much sense out of them as possible and also be able to search by basename, fullname, method name, and selector name.
llvm-svn: 178608
Reimplemented the NSDictionary synthetic children provider for added performance.
Instead of generating pairs by running an expression, we now create a pair type using clang-level APIs and fill in a buffer with the pointers to key and value
This strategy takes the time required to dump a 10k items __NSDictionaryM from ~45s to <4s
llvm-svn: 178601
Fixing a bug where LLDB was not handling correctly CFStrings that have an explicit length but no NULL terminator
The data formatter was showing garbled data as part of the summary
The fix is to explicitly figure out the explicit length if we need to (bitfields tell us when that is the case) and use that as a size delimiter
llvm-svn: 178577
Don't crash when there is no register context for a thread with kernel debugging. The kernel debugging uses the OperatingSystemPlugin that may behave badly when trying to get thread state, so be prepared to have invalid register contexts in threads.
llvm-svn: 178574
Note: although it is now possible to declare blocks
and call them inside the same expression, we do not
generate correct block descriptors so these blocks
cannot be passed to functions like dispatch_async.
<rdar://problem/12578656>
llvm-svn: 178509
- process in 'unloaded' state was (incorrectly) considered to be alive by POSIX plugin
- above caused a regression in TestProcessLaunch cases
llvm-svn: 178493
- Check that process attach succeeded before attempting to WaitForProcessToStop (observed to cause hangs on Linux)
- Update comment in TestHelloWorld case -- attaching by name still broken
llvm-svn: 178491
they are probably trivial. This means that we
don't confuse Clang about whether a class is
trivially copy constructible. It can figure
that out itself as long as we don't explicitly
feed it the constructors.
If the class is trivially copy-constructible,
this can change the ABI that Clang uses to call
functions that return that class (e.g., by making
the object be returned in a register), so this
is quite important for correctness.
<rdar://problem/13457741>
llvm-svn: 178411
ASTContexts that will not stay around. Before, we
did this in a very half-hearted way. Now we maintain
work queues of all Decls that need to be completed
before the source ASTContext can go away; we then
expunge their origins completely.
<rdar://problem/13511875>
llvm-svn: 178410
“process attach” should ask the same questions as process launch if there is a current process.
“process connect” then “process launch” or “process attach” should actually work.
<rdar://problem/13524210>
<rdar://problem/13524208>
<rdar://problem/13488919>
llvm-svn: 178324
PC relative loads are missing disassembly comments when disassembled in a live process.
This issue was because some sections, like __TEXT and __DATA in libobjc.A.dylib, were being moved when they were put into the dyld shared cache. This could also affect any other system that slides sections individually.
The solution is to keep track of wether the bytes we will disassemble are from an executable file (file address), or from a live process (load address). We now do the right thing based off of this input in all cases.
llvm-svn: 178315
Partial fix for the above radar.
Call ThreadList::Clear() in the ThreadList destructor so if any other threads currently have the thread list mutex, we won't destroy the list for them while they are using it. ThreadList::Clear() takes the mutex and clears the thread list contents.
llvm-svn: 178257
- Includes a stub for AVX support in the x86-64 register context and a failing test for register sets that are unavailable.
Thanks to Greg Clayton for his review feedback.
llvm-svn: 178252
- All Linux logging channels now use a single global instance of lldb_private::Log, to handle the case of logging during process tear down.
- Also removed a single use of LogSP in FreeBSD and fixed a typo in a comment while reading through ProcessKDPLog.
Reviewed by Daniel Malea.
llvm-svn: 178242
Holding the Python lock while we call the Python C API to post-process objects returned from the OS plugins
This should avoid issues where some Python objects get invalidated while we are in the middle of processing them and we end up with an invalid Python state and a crash
llvm-svn: 178206
LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.
All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down.
llvm-svn: 178191
With this notion, if parties outside the ScriptInterpreter itself need to acquire a lock on script APIs, they can do so by a pattern like this:
{
auto lock = interpeter->AcquireInterpreterLock();
// do whatever you need to do...
} // lock will automatically be released here
This might be useful for classes that use the Python convenience objects (e.g. PythonDictionary) to ensure they keep the underlying interpreter in a safe and controlled condition while they call through the C API functions
Of course, the ScriptInterpreter still manages its internal locking correctly when necessary :-)
llvm-svn: 178189
The algorithm to access an item in a __NSArrayM was not reacting properly to deletions
The fix is to use a smarter formula that accounts for items shifting and the resulting notion of offsets in the table
llvm-svn: 178076
- Making an error message more consistent
- Ensuring the element size is not zero before using it in a modulus
- Properly using target settings to cap the std::list element count
- Removing spurious element size calculations that were unused
- Removing spurious capping in std::map
llvm-svn: 178057
ValueObjects themselves use DumpValueObjectOptions as the currency for the same purpose
The code to convert between these two units was replicated (to varying degrees of correctness) in several spots in the code
This checkin provides one and only one (and hopefully correct :-) entry point for this conversion
llvm-svn: 178044
Functions in "(anonymous namespace)" was causing LLDB to crash when trying to complete a type and it would also cause functions arguments to appear in wrong place in frame display when showing function arguments.
llvm-svn: 177965
Make register read and write accept $<regname> as valid.
This allows:
(lldb) reg read rbx
rbx = 0x0000000000000000
(lldb) reg read $rbx
rbx = 0x0000000000000000
(lldb) reg write $rbx 1
(lldb) reg read $rbx
rbx = 0x0000000000000001
to function correctly
It is not done at the RegisterContext level because we should keep the internal API clean of this user-friendly behavior and name registers appropriately.
If this ends up being needed in more places we can reconsider.
llvm-svn: 177961
Ashok Thirumurthi