| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
checking the validity of the shared pointer prior to using it.
Fixed the GDB remote plug-in to once again watch for a reply from the "k"
packet, and fixed the logic to make sure the thread requesting the kill
and the async thread play nice (and very quickly) by synchronizing the
packet sending and reply. I also tweaked some of the shut down packet
("k" kill, "D" detach, and the halt packet) to make sure they do the right
thing.
Fixed "StateType Process::WaitForProcessStopPrivate (...)" to correctly pass
the timeout along to WaitForStateChangedEventsPrivate() and made the function
behave correctly with respect to timing out.
Added separate STDIN, STDOUT, and STDERR support to debugserver. Also added
the start of being able to set the working directory for the inferior process.
llvm-svn: 124049
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Thanks Bruce!
llvm-svn: 123083
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
control-c)
and end-of-file (often control-d).
llvm-svn: 119837
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
not release it by making sure a mutex locker object is appropriately used.
llvm-svn: 112996
|
| |
|
|
|
|
|
| |
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
|
|
|
llvm-svn: 105619
|
