threads that we spawn let us know when they are going away and that we
don't timeout waiting for a message from threads that have gone away.
We also now don't expect the "k" packet (kill) to send a response. This
greatly speeds up debugger shutdown performance. The test suite now runs
quite a bit faster.
Added a fix to the variable display code that fixes the display of
base classes. We were assuming the virtual or normal base class offsets
were being given in bit sizes, but they were being given as character
sizes, so we needed to multiply the offset by 8. This wasn't affecting
the expression parser, but it was affecting the correct display of C++
class base classes and all of their children.
llvm-svn: 124024
while the inferior is running) to be fast. The previous code would always
cause the sender to timeout, yet still return success due to the way we
were waiting for a value (incorrect value) to change. Now the ProcessGDBRemote
plug-in has a public and private "is running" predicate. This allows things
that need to send async packets to interrupt and wait for the private "is running"
state to be flipped to false, and then resume quickly with no timeout.
llvm-svn: 123903
I added support for asking if the GDB remote server supports thread suffixes
for packets that should be thread specific (register read/write packets) because
the way the GDB remote protocol does it right now is to have a notion of a
current thread for register and memory reads/writes (set via the "$Hg%x" packet)
and a current thread for running ("$Hc%x"). Now we ask the remote GDB server
if it supports adding the thread ID to the register packets and we enable
that feature in LLDB if supported. This stops us from having to send a bunch
of packets that update the current thread ID to some value which is prone to
error, or extra packets.
llvm-svn: 123762
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
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
do. Closing on EOF is an option that can be set on the
lldb_private::Communication or the lldb::SBCommunication objects after they
are created. Of course the EOF support isn't hooked up, so they don't do
anything at the moment, but they are left in so when the code is fixed, it
will be easy to get working again.
llvm-svn: 120885
an error saying the resume timed out. Previously the thread that was trying
to resume the process would eventually call ProcessGDBRemote::DoResume() which
would broadcast an event over to the async GDB remote thread which would sent the
continue packet to the remote gdb server. Right after this was sent, it would
set a predicate boolean value (protected by a mutex and condition) and then the
thread that issued the ProcessGDBRemote::DoResume() would then wait for that
condition variable to be set. If the async gdb thread was too quick though, the
predicate boolean value could have been set to true and back to false by the
time the thread that issued the ProcessGDBRemote::DoResume() checks the boolean
value. So we can't use the predicate value as a handshake. I have changed the code
over to using a Event by having the GDB remote communication object post an
event:
GDBRemoteCommunication::eBroadcastBitRunPacketSent
This allows reliable handshaking between the two threads and avoids the erroneous
ProcessGDBRemote::DoResume() errors.
Added a host backtrace service to allow in process backtraces when trying to track
down tricky issues. I need to see if LLVM has any backtracing abilities abstracted
in it already, and if so, use that, but I needed something ASAP for the current issue
I was working on. The static function is:
void
Host::Backtrace (Stream &strm, uint32_t max_frames);
And it will backtrace at most "max_frames" frames for the current thread and can be
used with any of the Stream subclasses for logging.
llvm-svn: 120793
Add bool member to Communication class indicating whether the
Connection should be closed on receiving an EOF or not. Update the
Connection read to return an EOF status when appropriate. Modify the
Communication class to pass the EOF along or not, and to close the
Connection or not, as appropriate.
llvm-svn: 120723
with the Interrupted bit set. Process::HandlePrivateEvent ignores Interrupted events.
DoHalt is changed to ensure that the stop even is processed, and an event with
the Interrupted event is posted. Finally ClangFunction is rationalized to use this
facility so the that Halt is handled more deterministically.
llvm-svn: 119453
don't crash if we disable logging when some code already has a copy of the
logger. Prior to this fix, logs were handed out as pointers and if they were
held onto while a log got disabled, then it could cause a crash. Now all logs
are handed out as shared pointers so this problem shouldn't happen anymore.
We are also using our new shared pointers that put the shared pointer count
and the object into the same allocation for a tad better performance.
llvm-svn: 118319
than just the entire log channel.
Add checks, where appropriate, to make sure a log channel/category has
not been disabled before attempting to write to it.
llvm-svn: 117715
enabled LLVM make style building and made this compile LLDB on Mac OS X. We
can now iterate on this to make the build work on both linux and macosx.
llvm-svn: 108009
