| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed the DisassemblerLLVMC disassembler to parse more efficiently instead of parsing opcodes over and over. The InstructionLLVMC class now only reads the opcode in the InstructionLLVMC::Decode function. This can be done very efficiently for ARM and architectures that have fixed opcode sizes. For x64 it still calls the disassembler to get the byte size.
Moved the lldb_private::Instruction::Dump(...) function up into the lldb_private::Instruction class and it now uses the function that gets the mnemonic, operandes and comments so that all disassembly is using the same code.
Added StreamString::FillLastLineToColumn() to allow filling a line up to a column with a character (which is used by the lldb_private::Instruction::Dump(...) function).
Modified the Opcode::GetData() fucntion to "do the right thing" for thumb instructions.
llvm-svn: 156532
|
|
|
|
|
|
|
|
| |
yanked out from under us prematurely on exit.
rdar://problem/11358062
llvm-svn: 156496
|
|
|
|
|
|
| |
without a format specified would in certain cases crash LLDB - This has also led to refactoring the by-type accessors for the data formatter subsystem. These now belong in our internal layer, and are just invoked by the public API stratum
llvm-svn: 156429
|
|
|
|
|
|
| |
method failed to operate on dynamic values. The fix consists in making the set operation fall through to the parent. We only actually allow this if the dynamic value is at a 0-offset from the parent, or the new value is 0. Other scenarios would need agreement on the actual meaning of the set operation (do we keep offsetting? do we just assume the user knows what they are doing?) so we prevent them, and let the expression parser deal with the complexity
llvm-svn: 156422
|
|
|
|
| |
llvm-svn: 156397
|
|
|
|
|
|
|
|
| |
Switch over to the "*-apple-macosx" for desktop and "*-apple-ios" for iOS triples.
Also make the selection process for auto selecting platforms based off of an arch much better.
llvm-svn: 156354
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
No one was using it and Locker(pthread_mutex_t *) immediately asserts for
pthread_mutex_t's that don't come from a Mutex anyway. Rather than try to make
that work, we should maintain the Mutex abstraction and not pass around the
platform implementation...
Make Mutex::Locker::Lock take a Mutex & or a Mutex *, and remove the constructor
taking a pthread_mutex_t *. You no longer need to call Mutex::GetMutex to pass
your mutex to a Locker (you can't in fact, since I made it private.)
llvm-svn: 156221
|
|
|
|
|
|
|
|
|
|
|
| |
that takes locks and potentially does allocations.
Just call SBDebugger::SetTerminalWidth on the driver's SBDebugger, which does the same job, but no locks.
Also add the value checking to SetTerminalWidth you get with SetInternalVariable(..., "term-width", ...).
rdar://problem/11310563
llvm-svn: 155665
|
|
|
|
| |
llvm-svn: 155642
|
|
|
|
|
|
|
| |
trying to mmap a file fails so parent caller function can
provide helpful information to use about what went wrong.
llvm-svn: 155617
|
|
|
|
|
|
| |
Previously, the categories were filled in but disabled by default. Tweaking test cases appropriately to keep working and do the right thing
llvm-svn: 155605
|
|
|
|
|
|
| |
an issue that was preventing Python oneliners from executing
llvm-svn: 155563
|
|
|
|
|
|
| |
bitfields - This patch ensures that (a) freeze-drying bitfields works correctly and (b) that we actually access bitfields through IR instead of the 'frame var en lieu of expr' shortcut, for added safety in corner cases that may arise
llvm-svn: 155494
|
|
|
|
|
|
|
|
|
|
| |
on a DataExtractor to be sizeof(void*) when the ValueObject came out of the expression parser
This worked correctly for 64-bit targets, but broke down data formatters in i386 mode. The formatters would try to read pointers out of the frozen-dried objects,
but were unable to do so because they would try fetching 8 bytes from a DataExtractor with only 4 bytes in it. This patch fixes the issue by always making the pointer-size
for a DataExtractor match the target setting.
llvm-svn: 155418
|
|
|
|
|
|
| |
enabled to the Module class. Used this new function in the DWARF parser.
llvm-svn: 155404
|
|
|
|
|
|
| |
Fixed an issue where we get NULL compile units back from the symbol vendor. We need symbol vendors to be able to quickly give an estimate of the compile units that they have without having to fully vette them first, so anyone getting compile units from a module should be able to deal with a NULL compile unit being returned for a given index.
llvm-svn: 155398
|
|
|
|
|
|
| |
our ability to find shared libraries by name. We now put it into the Module object name.
llvm-svn: 155223
|
|
|
|
| |
llvm-svn: 154535
|
|
|
|
|
|
|
|
| |
Cleaned up the Mutex::Locker and the ReadWriteLock classes a bit.
Also cleaned up the GDBRemoteCommunication class to not have so many packet functions. Used the "NoLock" versions of send/receive packet functions when possible for a bit of performance.
llvm-svn: 154458
|
|
|
|
|
|
| |
Work around a deadlocking issue where "SBDebugger::MemoryPressureDetected ()" is being called and is causing a deadlock. We now just try and get the lock when trying to trim down the unique modules so we don't deadlock debugger GUI programs until we can find the root cause.
llvm-svn: 154339
|
|
|
|
|
|
| |
contains a valid module, it will search that module first, then if we are still looking for matches (we have found less that "max_matches"), search in all of the other modules as well.
llvm-svn: 154186
|
|
|
|
|
|
| |
ModuleList::FindTypes where the old parameters that existing clients were using would have been compatible, so I renamed ModuleList::FindTypes to ModuleList::FindTypes2. Then I made fixes and verified I updated and fixed all client code, but I forgot to rename the function back to ModuleList::FindTypes(). I am doing that now and also cleaning up the C++ dynamic type code a bit.
llvm-svn: 154182
|
|
|
|
|
|
| |
class.
llvm-svn: 154055
|
|
|
|
| |
llvm-svn: 154028
|
|
|
|
|
|
| |
Fixed a potential crasher that could happen after Debugger::Terminate() was called.
llvm-svn: 153774
|
|
|
|
|
|
|
|
|
|
|
| |
ValueObject, and make sure that ValueObjects that
have null type names (because they have null types)
also have null qualified type names. This avoids
some potential crashes if
ValueObject::GetQualifiedTypeName tries to get the
name of their type by calling GetClangTypeImpl().
llvm-svn: 153718
|
|
|
|
| |
llvm-svn: 153683
|
|
|
|
|
|
| |
escape sequences by the summary provider shipping with LLDB - Added relevant test case code. Bonus points for identifying the source of the quotes :-)
llvm-svn: 153624
|
|
|
|
| |
llvm-svn: 153541
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
indicates that the section is thread specific. Any functions the load a module
given a slide, will currently ignore any sections that are thread specific.
lldb_private::Section now has:
bool
Section::IsThreadSpecific () const
{
return m_thread_specific;
}
void
Section::SetIsThreadSpecific (bool b)
{
m_thread_specific = b;
}
The ELF plug-in has been modified to set this for the ".tdata" and the ".tbss"
sections.
Eventually we need to have each lldb_private::Thread subclass be able to
resolve a thread specific section, but for now they will just not resolve. The
code for that should be trivual to add, but the address resolving functions
will need to be changed to take a "ExecutionContext" object instead of just
a target so that thread specific sections can be resolved.
llvm-svn: 153537
|
|
|
|
|
|
|
|
|
|
|
|
| |
SBValue is set up to always wrap a synthetic value when one is available.
A new setting enable-synthetic-value is provided on the target to disable this behavior.
There also is a new GetNonSyntheticValue() API call on SBValue to go back from synthetic to non-synthetic. There is no call to go from non-synthetic to synthetic.
The test suite has been changed accordingly.
Fallout from changes to type searching: an hack has to be played to make it possible to use maps that contain std::string due to the special name replacement operated by clang
Fixing a test case that was using libstdcpp instead of libc++ - caught as a consequence of said changes to type searching
llvm-svn: 153495
|
|
|
|
|
|
|
|
|
|
| |
Fixed type lookups to "do the right thing". Prior to this fix, looking up a type using "foo::bar" would result in a type list that contains all types that had "bar" as a basename unless the symbol file was able to match fully qualified names (which our DWARF parser does not).
This fix will allow type matches to be made based on the basename and then have the types that don't match filtered out. Types by name can be fully qualified, or partially qualified with the new "bool exact_match" parameter to the Module::FindTypes() method.
This fixes some issue that we discovered with dynamic type resolution as well as improves the overall type lookups in LLDB.
llvm-svn: 153482
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the feature that allowed the user to have things like:
class Base { ... };
class Derived : public Base { ... };
and have formatters defined for Base work automatically for Derived.
This feature turned out to be too expensive since it requires completing types.
This patch takes care of removing cascading (other than typedefs chain cascading), updating the test suite accordingly, and adding required Cocoa class names to keep the AppKit formatters working
llvm-svn: 153272
|
|
|
|
|
|
| |
when using the "frame variable" or "target variable" commands.
llvm-svn: 153266
|
|
|
|
|
|
|
|
|
| |
the migration to ModuleSpec objects this broke and is now fixed.
Also fixed a case in the darwin kernel dynamic loader where we just need to
trust the load address of the kernel if we can't read it from memory.
llvm-svn: 153164
|
|
|
|
| |
llvm-svn: 153113
|
|
|
|
| |
llvm-svn: 153106
|
|
|
|
| |
llvm-svn: 153101
|
|
|
|
|
|
| |
enough for us.
llvm-svn: 153076
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
following the naming pattern
Changes to synthetic children:
- the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points
this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed
- making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly)
claim to itself be synthetic
- cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible
- major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself
- removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place)
Some clean ups to the summary generation code
Centralized the code that clears out user-visible strings and data in ValueObject
More efficient summaries for libc++ containers
llvm-svn: 153061
|
|
|
|
|
|
|
|
|
|
| |
Fixed a case where the source path remappings on the module were too expensive to
use when we try to verify (stat the file system) that the remapped path points to
a valid file. Now we will use the lldb_private::Module path remappings (if any) when
parsing the debug info without verifying that the paths exist so we don't slow down
line table parsing speeds.
llvm-svn: 153059
|
|
|
|
|
|
| |
Use the metadata in the dSYM bundle Info.plist to remap source paths when they keys are available.
llvm-svn: 152836
|
|
|
|
|
|
| |
things-went-wrong situations. Previously they would say nothing or log failures to the Python console
llvm-svn: 152673
|
|
|
|
| |
llvm-svn: 152599
|
|
|
|
|
|
|
|
|
|
|
| |
uses internally to provide summaries
This has been done for those summaries where the difference is only cosmetic (e.g. naming things as items instead of values, ...)
The LLDB output style has been preserved when it provides more information (e.g. telling the type as well as the value of an NSNumber)
Test cases have been updated to reflect the updated output style where necessary
llvm-svn: 152592
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
std::string has a summary provider
std::vector std::list and std::map have both a summary and a synthetic children provider
Given the usage of a custom namespace (std::__1::classname) for the implementation of libc++, we keep both libstdcpp and libc++ formatters enabled at the same time since that raises no conflicts and enabled for seamless transition between the two
The formatters for libc++ reside in a libcxx category, and are loaded from libcxx.py (to be found in examples/synthetic)
The formatters-stl test cases have been divided to be separate for libcxx and libstdcpp. This separation is necessary because
(a) we need different compiler flags for libc++ than for libstdcpp
(b) libc++ inlines a lot more than libstdcpp and some code changes were required to accommodate this difference
llvm-svn: 152570
|
|
|
|
|
|
| |
Don't show variable values in Xcode when they are out of scope. This allows Xcode to step a lot faster when there are many variables in the variables view.
llvm-svn: 152380
|
|
|
|
|
|
|
|
| |
is turned off.
<rdar://problem/10975912>
llvm-svn: 152376
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
children, instead of an std::vector
This solves an issue where a ValueObject was getting a wrong children count (usually, a huge value) and trying to resize the vector of children to fit that many ValueObject*
Added a loop detection algorithm to the synthetic children provider for std::list
Added a few more checks to the synthetic children provider for std::vector
Both std::list and std::vector's synthetic children providers now cache the count of children instead of recomputing it every time
std::map has a field that stores the count, so there is little need to cache it on our side
llvm-svn: 152371
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
shouldn't compile any of the XPC support code.
Update macosx/Host.mm to use that define.
Add a LLDB_DISABLE_PYTHON ifdef block around a new function in
Core/FormatManager.cpp.
<rdar://problem/10942125>
llvm-svn: 152293
|