| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
I previously fixed a bug in the SocketAddress class where SocketAddress::GetPort() wasn't using ntohs() on the port number in the structures.
After fixing this, it broke places where we weren't using ntohs() and htons() correctly.
<rdar://problem/15767514>
llvm-svn: 198902
|
|
|
|
|
|
|
|
|
|
| |
parameter is redundant as this information is already provided by the ProcessAttachInfo parameter.
CC: lldb-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2463
llvm-svn: 197923
|
|
|
|
|
|
| |
This 'const' is not required and prevent us to defer the launch to the Host layer.
llvm-svn: 196837
|
|
|
|
|
|
|
|
|
|
| |
handshake with the launched debugserver.
This helps ensure that the launched debugserver is ready and listening for a connection. Prior to this we had a race condition.
Consolidate the launching of debugserver into a single place: a static function in GDBRemoteCommunication.
llvm-svn: 196401
|
|
|
|
|
|
|
|
|
|
| |
pure virtual base class and made StackFrame a subclass of that. As
I started to build on top of that arrangement today, I found that it
wasn't working out like I intended. Instead I'll try sticking with
the single StackFrame class -- there's too much code duplication to
make a more complicated class hierarchy sensible I think.
llvm-svn: 193983
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
defines a protocol that all subclasses will implement. StackFrame
is currently the only subclass and the methods that Frame vends are
nearly identical to StackFrame's old methods.
Update all callers to use Frame*/Frame& instead of pointers to
StackFrames.
This is almost entirely a mechanical change that touches a lot of
the code base so I'm committing it alone. No new functionality is
added with this patch, no new subclasses of Frame exist yet.
I'll probably need to tweak some of the separation, possibly moving
some of StackFrame's methods up in to Frame, but this is a good
starting point.
<rdar://problem/15314068>
llvm-svn: 193907
|
|
|
|
| |
llvm-svn: 189317
|
|
|
|
|
|
|
|
|
|
|
| |
Added a setting to control timeout for kdp response packets. While I was at it, I also added a way to control the response timeout for gdb-remote packets.
KDP defaults to 5 seconds, and GDB defaults to 1 second. These were the default values that were in the code prior to adding these settings.
(lldb) settings set plugin.process.gdb-remote.packet-timeout 10
(lldb) settings set plugin.process.kdp-remote.packet-timeout 10
llvm-svn: 186360
|
|
|
|
|
|
| |
extraction were moved causing them to be reversed.
llvm-svn: 186020
|
|
|
|
|
|
| |
deal with getting a reply from a previous packet without resending the packet again.
llvm-svn: 185988
|
|
|
|
|
|
| |
<rdar://problem/13793059>
llvm-svn: 185400
|
|
|
|
|
|
|
|
|
|
| |
names when specifying the DynamicLoaderDarwinKernel.
ProcessGDBRemote wasn't setting the dyld string any more; remove
the remaining code tracking the dyld plugin name altogether from
that process plugin.
llvm-svn: 181658
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
<rdar://problem/13594769>
Main changes in this patch include:
- cleanup plug-in interface and use ConstStrings for plug-in names
- Modfiied the BSD Archive plug-in to be able to pick out the correct .o file when .a files contain multiple .o files with the same name by using the timestamp
- Modified SymbolFileDWARFDebugMap to properly verify the timestamp on .o files it loads to ensure we don't load updated .o files and cause problems when debugging
The plug-in interface changes:
Modified the lldb_private::PluginInterface class that all plug-ins inherit from:
Changed:
virtual const char * GetPluginName() = 0;
To:
virtual ConstString GetPluginName() = 0;
Removed:
virtual const char * GetShortPluginName() = 0;
- Fixed up all plug-in to adhere to the new interface and to return lldb_private::ConstString values for the plug-in names.
- Fixed all plug-ins to return simple names with no prefixes. Some plug-ins had prefixes and most ones didn't, so now they all don't have prefixed names, just simple names like "linux", "gdb-remote", etc.
llvm-svn: 181631
|
|
|
|
|
|
|
|
| |
starting a kdp communication session, instead of assuming darwin
kernel for any "non-EFI" kdp session.
<rdar://problem/13854098>
llvm-svn: 181566
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
namespace lldb_private {
class Thread
{
virtual lldb::StopInfoSP
GetPrivateStopReason() = 0;
};
}
To not be virtual. The lldb_private::Thread now handles the correct caching and will call a new pure virtual function:
namespace lldb_private {
class Thread
{
virtual bool
CalculateStopInfo() = 0;
}
}
This function must be overridden by thead lldb_private::Thread subclass and the only thing it needs to do is to set the Thread::StopInfo() with the current stop reason and return true, or return false if there is no stop reason. The lldb_private::Thread class will take care of calling this function only when it is required. This allows lldb_private::Thread subclasses to be a bit simpler and not all need to duplicate the cache and invalidation settings.
Also renamed:
lldb::StopInfoSP
lldb_private::Thread::GetPrivateStopReason();
To:
lldb::StopInfoSP
lldb_private::Thread::GetPrivateStopInfo();
Also cleaned up a case where the ThreadPlanStepOverBreakpoint might not re-set its breakpoint if the thread disappears (which was happening due to a bug when using the OperatingSystem plug-ins with memory threads and real threads).
llvm-svn: 181501
|
|
|
|
| |
llvm-svn: 181493
|
|
|
|
| |
llvm-svn: 181340
|
|
|
|
|
|
|
|
|
|
| |
the Linux buildbots
while we develop a better understanding of how to manage the thread lists in a platform-independant fashion.
Reviewed by: Daniel Malea
llvm-svn: 181323
|
|
|
|
|
|
|
|
| |
force this to be a DynamicLoaderDarwinKernel debug
session even if we didn't get back a load address
for the kernel.
llvm-svn: 181264
|
|
|
|
|
|
|
| |
to not let it update the thread list or else we'll infinite recurse
call back to UpdateThreadList.
llvm-svn: 181106
|
|
|
|
|
|
|
|
|
|
| |
lldb_private::Thread subclasses were changed and the API was not respected properly.
This checkin aims to fix this. The process now has two thread lists: a real thread list for threads that are created by the lldb_private::Process subclass, and the user visible threads. The user visible threads are the same as the real threas when no OS plug-in in used. But when an OS plug-in is used, the user thread can be a combination of real and "memory" threads. Real threads can be placed inside of memory threads so that a thread appears to be different, but is still controlled by the actual real thread. When the thread list needs updating, the lldb_private::Process class will call the: lldb_private::Process::UpdateThreadList() function with the old real thread list, and the function is expected to fill in the new real thread list with the current state of the process. After this function, the process will check if there is an OS plug-in being used, and if so, it will give the old user thread list, the new real thread list and the OS plug-in will create the new user thread list from both of these lists. If there is no OS plug-in, the real thread list is the user thread list.
These changes keep the lldb_private::Process subclasses clean and no changes are required.
llvm-svn: 181091
|
|
|
|
|
|
| |
compute.
llvm-svn: 180898
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
<rdar://problem/13723772>
Modified the lldb_private::Thread to work much better with the OperatingSystem plug-ins. Operating system plug-ins can now return have a "core" key/value pair in each thread dictionary for the OperatingSystemPython plug-ins which allows the core threads to be contained with memory threads. It also allows these memory threads to be stepped, resumed, and controlled just as if they were the actual backing threads themselves.
A few things are introduced:
- lldb_private::Thread now has a GetProtocolID() method which returns the thread protocol ID for a given thread. The protocol ID (Thread::GetProtocolID()) is usually the same as the thread id (Thread::GetID()), but it can differ when a memory thread has its own id, but is backed by an actual API thread.
- Cleaned up the Thread::WillResume() code to do the mandatory parts in Thread::ShouldResume(), and let the thread subclasses override the Thread::WillResume() which is now just a notification.
- Cleaned up ClearStackFrames() implementations so that fewer thread subclasses needed to override them
- Changed the POSIXThread class a bit since it overrode Thread::WillResume(). It is doing the wrong thing by calling "Thread::SetResumeState()" on its own, this shouldn't be done by thread subclasses, but the current code might rely on it so I left it in with a TODO comment with an explanation.
llvm-svn: 180886
|
|
|
|
| |
llvm-svn: 180868
|
|
|
|
|
|
|
|
|
|
| |
process plugin (or in the
case of ProcessGDBRemote the stub we are talking to) know how to do that.
rdar://problem/13680832
llvm-svn: 180831
|
|
|
|
|
|
| |
the macros and just use C++11.
llvm-svn: 179805
|
|
|
|
|
|
|
|
| |
C++11 is being used. To do this, we follow what we have done for shared pointers and we define a STD_UNIQUE_PTR macro that can be used and it will "do the right thing". Due to some API differences in std::unique_ptr and due to the fact that we need to be able to compile without C++11, we can't use move semantics so some code needed to change so that it can compile with either C++.
Anyone wanting to use a unique_ptr or auto_ptr should now use the "STD_UNIQUE_PTR(TYPE)" macro.
llvm-svn: 179779
|
|
|
|
|
|
|
|
| |
Made some fixes to the OperatingSystemPython class:
- If any thread dictionary contains any "core=N" key/value pairs then the threads obtained from the lldb_private::Process itself will be placed inside the ThreadMemory threads and will be used to get the information for a thread.
- Cleaned up all the places where a thread inside a thread was causing problems
llvm-svn: 179405
|
|
|
|
|
|
| |
exists.
llvm-svn: 179326
|
|
|
|
|
|
| |
Don't crash when there is no register context for a thread with kernel debugging. The kernel debugging uses the OperatingSystemPlugin that may behave badly when trying to get thread state, so be prepared to have invalid register contexts in threads.
llvm-svn: 178574
|
|
|
|
|
|
|
|
|
| |
- All Linux logging channels now use a single global instance of lldb_private::Log, to handle the case of logging during process tear down.
- Also removed a single use of LogSP in FreeBSD and fixed a typo in a comment while reading through ProcessKDPLog.
Reviewed by Daniel Malea.
llvm-svn: 178242
|
|
|
|
|
|
|
|
| |
LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.
All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down.
llvm-svn: 178191
|
|
|
|
|
|
|
|
|
|
|
|
| |
useful,
and use it to keep from doing the OS Plugin UpdateThreadList while destroying, since
if that does anything that requires the API lock it may deadlock against whoever is
running the Process::Destroy.
<rdar://problem/13308627>
llvm-svn: 176375
|
|
|
|
|
|
| |
KDP packets.
llvm-svn: 176319
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- generate-vers.pl has to be called by cmake to generate the version number
- parallel builds not yet supported; dependency on clang must be explicitly specified
Tested on Linux.
- Building on Mac will require code-signing logic to be implemented.
- Building on Windows will require OS-detection logic and some selective directory inclusion
Thanks to Carlo Kok (who originally prepared these CMakefiles for Windows) and Ben Langmuir
who ported them to Linux!
llvm-svn: 175795
|
|
|
|
|
|
|
|
|
| |
BreakpointSites not breakpoints, it is confusing
to have it not named appropriately. Also in StopInfoMachException, we aren't testing for software or not software, just
whether the thing is a breakpoint we set. So don't use "software"...
llvm-svn: 175241
|
|
|
|
|
|
| |
Poor network connections aren't handled well; commands fail instead of retrying.
llvm-svn: 175198
|
|
|
|
|
|
|
|
|
|
|
|
| |
Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.
So I defined a new "lldb::offset_t" which should be used for all file offsets.
After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.
Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.
llvm-svn: 173463
|
|
|
|
|
|
| |
<rdar://problem/11597849>
llvm-svn: 170400
|
|
|
|
|
|
|
|
| |
- use macros from inttypes.h for format strings instead of OS-specific types
Patch from Matt Kopec!
llvm-svn: 168945
|
|
|
|
|
|
|
| |
use a DynamicLoaderStatic dynamic loader for the session
instead of a kernel or user dynamic loader.
llvm-svn: 166652
|
|
|
|
|
|
|
|
|
|
| |
Added commands to the KDP plug-in that allow sending raw commands through the KDP protocol. You specify a command byte and a payload as ASCII hex bytes, and the packet is created with a valid header/sequenceID/length and sent. The command responds with a raw ASCII hex string that contains all bytes in the reply including the header.
An example of sending a read register packet for the GPR on x86_64:
(lldb) process plugin packet send --command 0x07 --payload 0100000004000000
llvm-svn: 166346
|
|
|
|
|
|
| |
instead of asciified bytes. <rdar://problem/12522978>
llvm-svn: 166258
|
|
|
|
|
|
|
|
| |
breakpoints were set on consecutive addresses, the continue from the
first breakpoint would skip the second.
llvm-svn: 166000
|
|
|
|
|
|
| |
Memory write wasn't working (assert was firing) when writing memory.
llvm-svn: 165848
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ProcessSP. We can't create Threads with a NULL ProcessSP, so it makes no sense to use the SP.
Then make the Thread a Broadcaster, and get it to broadcast when the selected frame is changed (but only from the Command Line) and when Thread::ReturnFromFrame
changes the stack.
Made the Driver use this notification to print the new thread status rather than doing it in the command.
Fixed a few places where people were setting their broadcaster class by hand rather than using the static broadcaster class call.
<rdar://problem/12383087>
llvm-svn: 165640
|
|
|
|
| |
llvm-svn: 165192
|
|
|
|
|
|
|
|
|
|
| |
remove the duplicates of this code in ProcessGDBRemote and ProcessKDP.
These two Process plugins will hardcode their DynamicLoader name to be
the DynamicLoaderDarwinKernel so the correct DynamicLoader is picked,
and return the kernel load address as the ImageInfosAddress.
<rdar://problem/12417038>
llvm-svn: 165080
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
loaded at a random offset).
To get the kernel's UUID and load address I need to send a kdp
packet so I had to implement the kernel relocation (and attempt to
find the kernel if none was provided to lldb already) in ProcessKDP
-- but this code really properly belongs in DynamicLoaderDarwinKernel.
I also had to add an optional Stream to ConnectRemote so
ProcessKDP::DoConnectRemote can print feedback about the remote kernel's
UUID, load address, and notify the user if we auto-loaded the kernel via
the UUID.
<rdar://problem/7714201>
llvm-svn: 164881
|
|
|
|
|
|
| |
More KDP debugging process. We can not set breakpoints, hit them, resume, step and detach while running.
llvm-svn: 164584
|