by LLDB. Instead of being materialized into the input structure
passed to the expression, variables are left in place and pointers
to them are materialzied into the structure. Variables not resident
in memory (notably, registers) get temporary memory regions allocated
for them.
Persistent variables are the most complex part of this, because they
are made in various ways and there are different expectations about
their lifetime. Persistent variables now have flags indicating their
status and what the expectations for longevity are. They can be
marked as residing in target memory permanently -- this is the
default for result variables from expressions entered on the command
line and for explicitly declared persistent variables (but more on
that below). Other result variables have their memory freed.
Some major improvements resulting from this include being able to
properly take the address of variables, better and cleaner support
for functions that return references, and cleaner C++ support in
general. One problem that remains is the problem of explicitly
declared persistent variables; I have not yet implemented the code
that makes references to them into indirect references, so currently
materialization and dematerialization of these variables is broken.
llvm-svn: 123371
A race condition exists between StopReadThread and the reader thread proper.
When StopReadThread sets m_read_thread_enabled to false the reader thread can
terminate and set m_read_thread to LLDB_INVALID_HOST_THREAD on exit. Thus calls
to ThreadCancel or ThreadJoin in StopReadThread can be passed an invalid handle.
This patch removes the race by using m_read_thread_enabled as the flag thru
which the reader thread can notify the parent thread of early/abnormal
termination.
llvm-svn: 123309
SymbolFileDWARFDebugMap handles the parsing of OSO stabs which are effectively a
Mach-O specific feature and is incompatible with other object file formats.
llvm-svn: 123308
Previously we would be posting a "FAILED" message to the log channel even when
the operation succeeded.
Also, take this opportunity to add braces thus eliminating an "ambiguous else"
compiler warning.
llvm-svn: 123306
When debugging, if an expression hits a SIGABRT, it the expression ends up
completing and stopping due the the "SIGABRT". Then the next thing that runs
(another expression, or continuing the program) ends up progating the SIGABRT
and causing the parent processes to die.
We should probably think of a different solution where we suppress any signal
that resulted due to an expression, or we modifyin the UnixSignals class to
contain a row for "suppress for expression".
So the settings for SIGABRT are: suppress = true, stop = true, and
notify = true.
llvm-svn: 123157
a method:
void RegisterContext::InvalidateIfNeeded (bool force);
Each time this function is called, when "force" is false, it will only call
the pure virtual "virtual void RegisterContext::InvalideAllRegisters()" if
the register context's stop ID doesn't match that of the process. When the
stop ID doesn't match, or "force" is true, the base class will clear its
cached registers and the RegisterContext will update its stop ID to match
that of the process. This helps make it easier to correctly flush the register
context (possibly from multiple locations depending on when and where new
registers are availabe) without inadvertently clearing the register cache
when it doesn't need to be.
Modified the ProcessGDBRemote plug-in to be much more efficient when it comes
to:
- caching the expedited registers in the stop reply packets (we were ignoring
these before and it was causing us to read at least three registers every
time we stopped that were already supplied in the stop reply packet).
- When a thread has no stop reason, don't keep asking for the thread stopped
info. Prior to this fix we would continually send a qThreadStopInfo packet
over and over when any thread stop info was requested. We now note the stop
ID that the stop info was requested for and avoid multiple requests.
Cleaned up some of the expression code to not look for ClangExpressionVariable
objects up by name since they are now shared pointers and we can just look for
the exact pointer match and avoid possible errors.
Fixed an bug in the ValueObject code that would cause children to not be
displayed.
llvm-svn: 123127
new "hexname" key for the "key:value;" duple that is part of the packet. This
allows for thread names to contain special characters such as $ # : ; + -
Debugserver now detects if the thread name contains special characters and
sends the chars in hex format if needed.
llvm-svn: 123053
frames, UnwindLLDB could create the incorrect RegisterContext for a given
stack frame because it was using the frame index (not the concrete frame
index). This was causing crashes when doing backtraces through the
SBFrame::GetFP() because a NULL register context was being returned for the
deepest stack frame.
llvm-svn: 123052
was being searched and sorted using a shared pointer as the value which means
the pointer value was what was being searched for. This means that anytime
you did a stack backtrace, the collection of FuncUnwinders doubled and then
the array or shared pointer got sorted (by pointer value), so you had an ever
increasing collection of shared pointer where a match was never found. This
means we had a ton of duplicates in this table and would cause issues after
one had been debugging for a long time.
llvm-svn: 123045
subclasses will automatically be able to take advantage of caching. The
cache line size is set to 512 by default.
This greatly speeds up stack backtraces on MacOSX when using the
ProcessGDBRemote process plug-in since only about 6300 packets per second
can be sent.
Initial speedups show:
Prior to caching: 10,000 stack frames took 5.2 seconds
After caching: 10,000 stack frames in 240 ms!
About a 20x speedup!
llvm-svn: 122996
cache even when a valid process exists. Previously, Target::ReadMemory would
read from the process if there was a valid one and then fallback to the
object file cache.
llvm-svn: 122989
an issue with the way the UnwindLLDB was handing out RegisterContexts: it
was making shared pointers to register contexts and then handing out just
the pointers (which would get put into shared pointers in the thread and
stack frame classes) and cause double free issues. MallocScribble helped to
find these issues after I did some other cleanup. To help avoid any
RegisterContext issue in the future, all code that deals with them now
returns shared pointers to the register contexts so we don't end up with
multiple deletions. Also now that the RegisterContext class doesn't require
a stack frame, we patched a memory leak where a StackFrame object was being
created and leaked.
Made the RegisterContext class not have a pointer to a StackFrame object as
one register context class can be used for N inlined stack frames so there is
not a 1 - 1 mapping. Updates the ExecutionContextScope part of the
RegisterContext class to never return a stack frame to indicate this when it
is asked to recreate the execution context. Now register contexts point to the
concrete frame using a concrete frame index. Concrete frames are all of the
frames that are actually formed on the stack of a thread. These concrete frames
can be turned into one or more user visible frames due to inlining. Each
inlined stack frame has the exact same register context (shared via shared
pointers) as any parent inlined stack frames all the way up to the concrete
frame itself.
So now the stack frames and the register contexts should behave much better.
llvm-svn: 122976
In particular, we are looking to ignore the "#pragma mark" construct which GCC
warns about on platforms other than Darwin. This cleans up diagnostic output
significantly.
llvm-svn: 122974
Fixed the display of complex numbers in lldb_private::DataExtractor::Dump(...)
and also fixed other edge display cases in lldb_private::ClangASTType::DumpTypeValue(...).
llvm-svn: 122895
This code was a temporary workaround due to the lack of a dynamic loader plugin
for the Linux platform that has bit rotted over time. Instead of replacing this
hack with another a proper plugin will be developed instead.
llvm-svn: 122837
Sean Callanan