Fixed an issue with stepping where the stack frame list could get changed out from underneath you when multiple threads start accessing frame info.
llvm-svn: 153627
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
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
Each platform now knows if it can handle an architecture and a platform can be found using an architecture. Each platform can look at the arch, vendor and OS and know if it should be used or not.
llvm-svn: 153104
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
load notification for the first load) then we will set it the runtime to NULL and won't re-search for it.
Added a way for the dynamic loader to force a re-search, since it knows the world has changed.
llvm-svn: 152453
This takes two important changes:
- Calling blocks is now supported. You need to
cast their return values, but that works fine.
- We now can correctly run JIT-compiled
expressions that use floating-point numbers.
Also, we have taken a fix that allows us to
ignore access control in Objective-C as in C++.
llvm-svn: 152286
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
Fixed STDERR to not be opened as readable. Also cleaned up some of the code that implemented the file actions as some of the code was using the wrong variables, they now use the right ones (in for stdin, out for stdout, err for stderr).
llvm-svn: 152102
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
weak reference back to the Module. We were crashing when trying to make a
memory object file since it was trying to get the object in the Module
constructor before the "Module *" had been put into a shared pointer, and the
module was trying to initialize a weak pointer back to it.
llvm-svn: 151397
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
Objective-C classes. This allows LLDB to find
ivars declared in class extensions in modules other
than where the debugger is currently stopped (we
already supported this when the debugger was
stopped in the same module as the definition).
This involved the following main changes:
- The ObjCLanguageRuntime now knows how to hunt
for the authoritative version of an Objective-C
type. It looks for the symbol indicating a
definition, and then gets the type from the
module containing that symbol.
- ValueObjects now report their type with a
potential override, and the override is set if
the type of the ValueObject is an Objective-C
class or pointer type that is defined somewhere
other than the original reported type. This
means that "frame variable" will always use the
complete type if one is available.
- The ClangASTSource now looks for the complete
type when looking for ivars. This means that
"expr" will always use the complete type if one
is available.
- I added a testcase that verifies that both
"frame variable" and "expr" work.
llvm-svn: 151214
to the __PAGEZERO segment on darwin. The dynamic loader now correctly doesn't
slide __PAGEZERO and it also registers it as an invalid region of memory. This
allows us to not make any memory requests from the local or remote debug session
for any addresses in this region. Stepping performance can improve when uninitialized
local variables that point to locations in __PAGEZERO are attempted to be read
from memory as we won't even make the memory read or write request.
llvm-svn: 151128
objects for the backlink to the lldb_private::Process. The issues we were
running into before was someone was holding onto a shared pointer to a
lldb_private::Thread for too long, and the lldb_private::Process parent object
would get destroyed and the lldb_private::Thread had a "Process &m_process"
member which would just treat whatever memory that used to be a Process as a
valid Process. This was mostly happening for lldb_private::StackFrame objects
that had a member like "Thread &m_thread". So this completes the internal
strong/weak changes.
Documented the ExecutionContext and ExecutionContextRef classes so that our
LLDB developers can understand when and where to use ExecutionContext and
ExecutionContextRef objects.
llvm-svn: 151009
the lldb_private::StackFrame objects hold onto a weak pointer to the thread
object. The lldb_private::StackFrame objects the the most volatile objects
we have as when we are doing single stepping, frames can often get lost or
thrown away, only to be re-created as another object that still refers to the
same frame. We have another bug tracking that. But we need to be able to
have frames no longer be able to get the thread when they are not part of
a thread anymore, and this is the first step (this fix makes that possible
but doesn't implement it yet).
Also changed lldb_private::ExecutionContextScope to return shared pointers to
all objects in the execution context to further thread harden the internals.
llvm-svn: 150871
internals. The first part of this is to use a new class:
lldb_private::ExecutionContextRef
This class holds onto weak pointers to the target, process, thread and frame
and it also contains the thread ID and frame Stack ID in case the thread and
frame objects go away and come back as new objects that represent the same
logical thread/frame.
ExecutionContextRef objcets have accessors to access shared pointers for
the target, process, thread and frame which might return NULL if the backing
object is no longer available. This allows for references to persistent program
state without needing to hold a shared pointer to each object and potentially
keeping that object around for longer than it needs to be.
You can also "Lock" and ExecutionContextRef (which contains weak pointers)
object into an ExecutionContext (which contains strong, or shared pointers)
with code like
ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock());
llvm-svn: 150801
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
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
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
Currently, no code is using this feature, since we can hopefully rely on the new template support in SBType to get the same stuff done, but the support is there just in case it turns out to be useful for some future need.
llvm-svn: 149661
lldb.value()
It it designed to be given a lldb.SBValue object and it allows natural
use of a variable value:
pt = lldb.value(lldb.frame.FindVariable("pt"))
print pt
print pt.x
print pt.y
pt = lldb.frame.FindVariable("rectangle_array")
print rectangle_array[12]
print rectangle_array[5].origin.x
Note that array access works just fine and works on arrays or pointers:
pt = lldb.frame.FindVariable("point_ptr")
print point_ptr[5].y
Also note that pointer child accesses are done using a "." instead of "->":
print point_ptr.x
llvm-svn: 149464
frames might go away (the object itself, not the actual logical frame) when
we are single stepping due to the way we currently sometimes end up flushing
frames when stepping in/out/over. They later will come back to life
represented by another object yet they have the same StackID. Now when you get
a lldb::SBFrame object, it will track the frame it is initialized with until
the thread goes away or the StackID no longer exists in the stack for the
thread it was created on. It uses a weak_ptr to both the frame and thread and
also stores the StackID. These three items allow us to determine when the
stack frame object has gone away (the weak_ptr will be NULL) and allows us to
find the correct frame again. In our test suite we had such cases where we
were just getting lucky when something like this happened:
1 - stop at breakpoint
2 - get first frame in thread where we stopped
3 - run an expression that causes the program to JIT and run code
4 - run more expressions on the frame from step 2 which was very very luckily
still around inside a shared pointer, yet, not part of the current
thread (a new stack frame object had appeared with the same stack ID and
depth).
We now avoid all such issues and properly keep up to date, or we start
returning errors when the frame doesn't exist and always responds with
invalid answers.
Also fixed the UserSettingsController (not going to rewrite this just yet)
so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to
track when the master controller has already gone away and this allowed me to
pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer
needed.
llvm-svn: 149231
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
be fetched too many times and the DisassemblerLLVM was appending to strings
when the opcode, mnemonic and comment accessors were called multiple times
and if any of the strings were empty.
Also fixed the test suite failures from recent Objective C modifications.
llvm-svn: 148460
Greg Clayton