|
Revision tags: llvmorg-3.1.0-rc2, llvmorg-3.1.0-rc1 |
|
| #
37a0a24a |
| 11-Apr-2012 |
Greg Clayton <[email protected]> |
No functionality changes, mostly cleanup.
Cleaned up the Mutex::Locker and the ReadWriteLock classes a bit.
Also cleaned up the GDBRemoteCommunication class to not have so many packet functions. Us
No functionality changes, mostly cleanup.
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
show more ...
|
| #
0cd70866 |
| 09-Apr-2012 |
Greg Clayton <[email protected]> |
<rdar://problem/11202426>
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 tr
<rdar://problem/11202426>
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
show more ...
|
| #
12b834d6 |
| 29-Mar-2012 |
Greg Clayton <[email protected]> |
<rdar://problem/10103468>
Symbol files (dSYM files on darwin) can now be specified during program execution:
(lldb) target symbols add /path/to/symfile/a.out.dSYM/Contents/Resources/DWARF/a.out
Th
<rdar://problem/10103468>
Symbol files (dSYM files on darwin) can now be specified during program execution:
(lldb) target symbols add /path/to/symfile/a.out.dSYM/Contents/Resources/DWARF/a.out
This command can be used when you have a debug session in progress and want to add symbols to get better debug info fidelity.
llvm-svn: 153693
show more ...
|
| #
741f3f9a |
| 27-Mar-2012 |
Greg Clayton <[email protected]> |
lldb_private::Section objects have a boolean flag that can be set that indicates that the section is thread specific. Any functions the load a module given a slide, will currently ignore any section
lldb_private::Section objects have a boolean flag that can be set that 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
show more ...
|
| #
84db9105 |
| 26-Mar-2012 |
Greg Clayton <[email protected]> |
<rdar://problem/11113279>
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 ba
<rdar://problem/11113279>
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
show more ...
|
| #
86cc9829 |
| 19-Mar-2012 |
Enrico Granata <[email protected]> |
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a val
Massive enumeration name changes: a number of enums in ValueObject were not 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
show more ...
|
| #
e7612134 |
| 07-Mar-2012 |
Greg Clayton <[email protected]> |
<rdar://problem/10997402>
This fix really needed to happen as a previous fix I had submitted for calculating symbol sizes made many symbols appear to have zero size since the function that was calcu
<rdar://problem/10997402>
This fix really needed to happen as a previous fix I had submitted for calculating symbol sizes made many symbols appear to have zero size since the function that was calculating the symbol size was calling another function that would cause the calculation to happen again. This resulted in some symbols having zero size when they shouldn't. This could then cause infinite stack traces and many other side affects.
llvm-svn: 152244
show more ...
|
| #
0c489f58 |
| 01-Mar-2012 |
Enrico Granata <[email protected]> |
1) solving a bug where, after Jim's fixes to stack frames, synthetic children were not recalculated when necessary, causing them to get out of sync with live data 2) providing an updated list of tagg
1) solving a bug where, after Jim's fixes to stack frames, synthetic children were not recalculated when necessary, causing them to get out of sync with live data 2) providing an updated list of tagged pointers values for the objc_runtime module - hopefully this one is final 3) changing ValueObject::DumpValueObject to use an Options class instead of providing a bulky list of parameters to pass around this change had been laid out previously, but some clients of DumpValueObject() were still using the old prototype and some arguments were treated in a special way and passed in directly instead of through the Options class 4) providing new GetSummaryAsCString() and GetValueAsCString() calls in ValueObject that are passed a formatter object and a destination string and fill the string by formatting themselves using the formatter argument instead of the default for the current ValueObject 5) removing the option to have formats and summaries stick to a variable for the current stoppoint after some debate, we are going with non-sticky: if you say frame variable --format hex foo, the hex format will only be applied to the current command execution and not stick when redisplaying foo the other option would be full stickiness, which means that foo would be formatted as hex for its whole lifetime we are open to suggestions on what feels "natural" in this regard
llvm-svn: 151801
show more ...
|
| #
b9a01b39 |
| 26-Feb-2012 |
Greg Clayton <[email protected]> |
Made a ModuleSpec class in Module.h which can specify a module using one or more of the local path, platform path, associated symbol file, UUID, arch, object name and object offset. This allows many
Made a ModuleSpec class in Module.h which can specify a module using one or more of the local path, platform path, associated symbol file, UUID, arch, object name and object offset. This allows many of the calls that were GetSharedModule to reduce the number of arguments that were used in a call to these functions. It also allows a module to be created with a ModuleSpec which allows many things to be specified prior to any accessors being called on the Module class itself.
I was running into problems when adding support for "target symbol add" where you can specify a stand alone debug info file after debugging has started where I needed to specify the associated symbol file path and if I waited until after construction, the wrong symbol file had already been located. By using the ModuleSpec it allows us to construct a module with as little or as much information as needed and not have to change the parameter list.
llvm-svn: 151476
show more ...
|
| #
e72dfb32 |
| 24-Feb-2012 |
Greg Clayton <[email protected]> |
<rdar://problem/10103468>
I started work on being able to add symbol files after a debug session had started with a new "target symfile add" command and quickly ran into problems with stale Address
<rdar://problem/10103468>
I started work on being able to add symbol files after a debug session had started with a new "target symfile add" command and quickly ran into problems with stale Address objects in breakpoint locations that had lldb_private::Section pointers into modules that had been removed or replaced. This also let to grabbing stale modules from those sections. So I needed to thread harded the Address, Section and related objects.
To do this I modified the ModuleChild class to now require a ModuleSP on initialization so that a weak reference can created. I also changed all places that were handing out "Section *" to have them hand out SectionSP. All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild so all of the find plug-in, static creation function and constructors now require ModuleSP references instead of Module *.
Address objects now have weak references to their sections which can safely go stale when a module gets destructed.
This checkin doesn't complete the "target symfile add" command, but it does get us a lot clioser to being able to do such things without a high risk of crashing or memory corruption.
llvm-svn: 151336
show more ...
|
| #
c859e2d5 |
| 13-Feb-2012 |
Greg Clayton <[email protected]> |
Full core file support has been added for mach-o core files.
Tracking modules down when you have a UUID and a path has been improved.
DynamicLoaderDarwinKernel no longer parses mach-o load commands
Full core file support has been added for mach-o core files.
Tracking modules down when you have a UUID and a path has been improved.
DynamicLoaderDarwinKernel no longer parses mach-o load commands and it now uses the memory based modules now that we can load modules from memory.
Added a target setting named "target.exec-search-paths" which can be used to supply a list of directories to use when trying to look for executables. This allows one or more directories to be used when searching for modules that may not exist in the SDK/PDK. The target automatically adds the directory for the main executable to this list so this should help us in tracking down shared libraries and other binaries.
llvm-svn: 150426
show more ...
|
| #
d4a7c123 |
| 11-Feb-2012 |
Sean Callanan <[email protected]> |
Made the "--no-inlines" option on "target modules lookup" also work with the "--function" option, so you can search for functions that aren't inlined. This is the same query that the expression pars
Made the "--no-inlines" option on "target modules lookup" also work with the "--function" option, so you can search for functions that aren't inlined. This is the same query that the expression parser makes, so it's good for diagnosing situations where the expression parser doesn't find a function you think should be there.
llvm-svn: 150289
show more ...
|
| #
f6172c2c |
| 11-Feb-2012 |
Sean Callanan <[email protected]> |
Make the output from "target modules lookup -n" prettier.
llvm-svn: 150285
|
| #
9df05fbb |
| 10-Feb-2012 |
Sean Callanan <[email protected]> |
Extended function lookup to allow the user to indicate whether inline functions are desired. This allows the expression parser, for instance, to filter out inlined functions when looking for function
Extended function lookup to allow the user to indicate whether inline functions are desired. This allows the expression parser, for instance, to filter out inlined functions when looking for functions it can call.
llvm-svn: 150279
show more ...
|
| #
c3776bf2 |
| 09-Feb-2012 |
Greg Clayton <[email protected]> |
First pass at mach-o core file support is in. It currently works for x86_64 user space programs. The core file support is implemented by making a process plug-in that will dress up the threads and s
First pass at mach-o core file support is in. It currently works for x86_64 user space programs. The core file support is implemented by making a process plug-in that will dress up the threads and stack frames by using the core file memory.
Added many default implementations for the lldb_private::Process functions so that plug-ins like the ProcessMachCore don't need to override many many functions only to have to return an error.
Added new virtual functions to the ObjectFile class for extracting the frozen thread states that might be stored in object files. The default implementations return no thread information, but any platforms that support core files that contain frozen thread states (like mach-o) can make a module using the core file and then extract the information. The object files can enumerate the threads and also provide the register state for each thread. Since each object file knows how the thread registers are stored, they are responsible for creating a suitable register context that can be used by the core file threads.
Changed the process CreateInstace callbacks to return a shared pointer and to also take an "const FileSpec *core_file" parameter to allow for core file support. This will also allow for lldb_private::Process subclasses to be made that could load crash logs. This should be possible on darwin where the crash logs contain all of the stack frames for all of the threads, yet the crash logs only contain the registers for the crashed thrad. It should also allow some variables to be viewed for the thread that crashed.
llvm-svn: 150154
show more ...
|
| #
c9660546 |
| 05-Feb-2012 |
Greg Clayton <[email protected]> |
<rdar://problem/10560053>
Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options:
"--header" or "-
<rdar://problem/10560053>
Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options:
"--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library)
Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file.
ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory.
Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory.
lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using:
bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed)
lldb::SBModule() now has a new constructor in the public interface:
SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr);
This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr".
llvm-svn: 149804
show more ...
|
| #
e1cd1be6 |
| 29-Jan-2012 |
Greg Clayton <[email protected]> |
Switching back to using std::tr1::shared_ptr. We originally switched away due to RTTI worries since llvm and clang don't use RTTI, but I was able to switch back with no issues as far as I can tell.
Switching back to using std::tr1::shared_ptr. We originally switched away due to RTTI worries since llvm and clang don't use RTTI, but I was able to switch back with no issues as far as I can tell. Once the RTTI issue wasn't an issue, we were looking for a way to properly track weak pointers to objects to solve some of the threading issues we have been running into which naturally led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared pointer from just a pointer, which is also easily solved using the std::tr1::enable_shared_from_this class.
The main reason for this move back is so we can start properly having weak references to objects. Currently a lldb_private::Thread class has a refrence to its parent lldb_private::Process. This doesn't work well when we now hand out a SBThread object that contains a shared pointer to a lldb_private::Thread as this SBThread can be held onto by external clients and if they end up using one of these objects we can easily crash.
So the next task is to start adopting std::tr1::weak_ptr where ever it makes sense which we can do with lldb_private::Debugger, lldb_private::Target, lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and many more objects now that they are no longer using intrusive ref counted pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive pointers).
llvm-svn: 149207
show more ...
|
| #
b26e6beb |
| 27-Jan-2012 |
Greg Clayton <[email protected]> |
Fixed an issue that could happen during global object destruction in our map that tracks all live Module classes. We must leak our mutex for our collection class as it might be destroyed in an order
Fixed an issue that could happen during global object destruction in our map that tracks all live Module classes. We must leak our mutex for our collection class as it might be destroyed in an order we can't control.
llvm-svn: 149131
show more ...
|
| #
6efba4fc |
| 26-Jan-2012 |
Greg Clayton <[email protected]> |
Fixed formats being able to be applied recursively when using: target variable -f <format> [args] frame variable -f <format> [args] expression -f <format> -- expr
llvm-svn: 149080
|
| #
e5136385 |
| 10-Jan-2012 |
Greg Clayton <[email protected]> |
When doing a "target modules lookup --address <addr>", show the file address in the module when dumping the information in addition to all info that we were previously showing.
llvm-svn: 147815
|
| #
d1767f05 |
| 08-Dec-2011 |
Greg Clayton <[email protected]> |
Added a new class called lldb_private::SymbolFileType which is designed to take a SymbolFile reference and a lldb::user_id_t and be used in objects which represent things in debug symbols that have t
Added a new class called lldb_private::SymbolFileType which is designed to take a SymbolFile reference and a lldb::user_id_t and be used in objects which represent things in debug symbols that have types where we don't need to know the true type yet, such as in lldb_private::Variable objects. This allows us to defer resolving the type until something is used. More specifically this allows us to get 1000 local variables from the current function, and if the user types "frame variable argc", we end up _only_ resolving the type for "argc" and not for the 999 other local variables. We can expand the use of this as needed in the future.
Modified the DWARFMappedHash class to be able to read the HashData that has more than just the DIE offset. It currently will read the atoms in the header definition and read the data correctly. Currently only the DIE offset and type flags are supported. This is needed for adding type flags to the .apple_types hash accelerator tables.
Fixed a assertion crash that would happen if we have a variable that had a DW_AT_const_value instead of a location where "location.LocationContains_DW_OP_addr()" would end up asserting when it tried to parse the variable location as a DWARF opcode list.
Decreased the amount of memory that LLDB would use when evaluating an expression by 3x - 4x for clang. There was a place in the namespace lookup code that was parsing all namespaces with a certain name in a DWARF file instead of stopping when it found the first match. This was causing all of the compile units with a matching namespace to get parsed into memory and causing unnecessary memory bloat.
Improved "Target::EvaluateExpression(...)" to not try and find a variable when the expression contains characters that would certainly cause an expression to need to be evaluated by the debugger.
llvm-svn: 146130
show more ...
|
| #
61e7a58c |
| 01-Dec-2011 |
Greg Clayton <[email protected]> |
Process IDs (lldb::pid_t) and thread IDs (lldb::tid_t) are now 64 bit. This will allow us to represent a process/thread ID using a pointer for the OS plug-ins where they might want to represent the
Process IDs (lldb::pid_t) and thread IDs (lldb::tid_t) are now 64 bit. This will allow us to represent a process/thread ID using a pointer for the OS plug-ins where they might want to represent the process or thread ID using the address of the process or thread structure.
llvm-svn: 145644
show more ...
|
| #
d0cff1ea |
| 30-Nov-2011 |
Johnny Chen <[email protected]> |
I broke the test suite (4 failures) with r145459 check-in. Fix the breakage by properly setting the result status before returning.
llvm-svn: 145507
|
| #
faa5c13d |
| 29-Nov-2011 |
Johnny Chen <[email protected]> |
Remove possible cut-and-paste code which doesn't belong.
llvm-svn: 145459
|
|
Revision tags: llvmorg-3.0.0, llvmorg-3.0.0-rc4 |
|
| #
2637f825 |
| 17-Nov-2011 |
Greg Clayton <[email protected]> |
Fixed an issue with the pthread_setspecific() where we weren't NULL-ing out the thread specific data and were destroying the thread specfic data more than once.
Also added the ability to ask a lldb:
Fixed an issue with the pthread_setspecific() where we weren't NULL-ing out the thread specific data and were destroying the thread specfic data more than once.
Also added the ability to ask a lldb::StateType if it is stopped with an additional paramter of "must_exist" which means that the state must be a stopped state for a process that still exists. This means that eStateExited and eStateUnloaded will no longer return true if "must_exist" is set to true.
llvm-svn: 144875
show more ...
|