As part of getting ConnectionFileDescriptor working on Windows,
there is going to be alot of platform specific work to be done.
As a result, the implementation is moving into Host. This patch
performs the code move and fixes up call-sites appropriately.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D5548
llvm-svn: 219143
There are several places where multiple threads are accessing the same variables simultaneously without any kind of protection. I propose using std::atomic<> to make it safer. I did a special build of lldb, using the google tool 'thread sanitizer' which identified many cases of multiple threads accessing the same memory. std::atomic is low overhead and does not use any locks for simple types such as int/bool.
See http://reviews.llvm.org/D5302 for more details.
Change by Shawn Best.
llvm-svn: 217818
This patch moves creates a thread abstraction that represents a
thread running inside the LLDB process. This is a replacement for
otherwise using lldb::thread_t, and provides a platform agnostic
interface to managing these threads.
Differential Revision: http://reviews.llvm.org/D5198
Reviewed by: Jim Ingham
llvm-svn: 217460
lldb's internal memory cache chunks that are read from the remote
system. For a remote connection that is especially slow, a user may
need to reduce it; reading a 512 byte chunk of memory whenever a
4-byte region is requested may not be the right decision in these
kinds of environments.
<rdar://problem/18175117>
llvm-svn: 217083
See http://reviews.llvm.org/D5108 for details.
This change does the following:
* eliminates the Process::GetUnixSignals() virtual method and replaces with a fixed getter.
* replaces the Process UnixSignals storage with a shared pointer.
* adds a Process constructor variant that can be passed the UnixSignalsSP. When the constructor without the UnixSignalsSP is specified, the Host's default UnixSignals is used.
* adds a host-specific version of GetUnixSignals() that is used when we need the host's appropriate UnixSignals variant.
* replaces GetUnixSignals() overrides in PlatformElfCore, ProcessGDBRemote, ProcessFreeBSD and ProcessLinux with code that appropriately sets the Process::UnixSignals for the process.
This change also enables some future patches that will enable llgs to be used for local Linux debugging.
llvm-svn: 216748
This change modifies the 'process launch' --disable-aslr option to take a boolean argument. If the user directly specifies --disable-aslr {true,false}, that setting will control whether the process is launched with ASLR disabled accordingly. In the event that the setting is not explicitly made on the process launch command line, then the value is retrieved from the target.disable-aslr setting (i.e. settings show target.disable-aslr).
llvm-svn: 215996
More specifically, this change can be summarized as follows:
1) Makes an lldbHostPosix library which contains code common to
all posix platforms.
2) Creates Host/FileSystem.h which defines a common FileSystem
interface.
3) Implements FileSystem.h in Host/windows and Host/posix.
4) Creates Host/FileCache.h, implemented in Host/common, which
defines a class useful for storing handles to open files needed
by the debugger.
Differential Revision: http://reviews.llvm.org/D4889
llvm-svn: 215775
FileAction was previously a nested class in ProcessLaunchInfo.
This led to some unfortunate style consequences, such as requiring
the AddPosixSpawnFileAction() funciton to be defined in the Target
layer, instead of the more appropriate Host layer. This patch
makes FileAction its own independent class in the Target layer,
and then moves AddPosixSpawnFileAction() into Host as a result.
Differential Revision: http://reviews.llvm.org/D4877
llvm-svn: 215649
result variable and use in in "Process::LoadImage" so that,
for instance, "process load" doesn't increment the return
variable number.
llvm-svn: 213440
The problem was that we have an IOHandler thread that services the IOHandler stack. The command interepter is on the top of the stack and it receives a "expression ..." command, and it calls the IOHandlerIsComplete() callback in the command interpereter delegate which runs an expression. This causes the IOHandlerProcessSTDIO to be pushed, but since we are running the code from the IOHandler thread, it won't get run. When CTRL+C is pressed, we do deliver the interrupt to the IOHandlerProcessSTDIO::Interrupt() function, but it was always writing 'i' to the interrupt pipe, even if we weren't actively reading from the debugger input and the pipes. This fix works around the issue by directly issuing the async interrupt to the process if the process is running.
A longer term more correct fix would to be run the IOHandler thread and have it just do the determination of the input and when complete input is received, run the code that handles that input on another thread and syncronize with that other thread to detect when more input is desired. That change is too big to make right now, so this fix will tide us over until we can get there.
<rdar://problem/16556228>
llvm-svn: 213196
This value gets set to a max uint32_t value when there is no known limit; otherwise,
it is set to a value appropriate for the platform. For the moment, only
Linux, FreeBSD and NetBSD set it to 16. All other platforms set it to
the max uint32_t value.
Modifies the Process private state thread names to fit within a 16-character limit
when the max thread name length is <= 16. These guarantee that the thread names
can be distinguished within the first 16 characters. Prior to this change, those
threads had names in the final dotted name segment that were not distinguishable
within the first 16 characters.
llvm-svn: 213183
This reverses out the options validators changes. We'll get these
back in once the changes to the output can be resolved.
Restores broken tests on FreeBSD, Linux, MacOSX.
Changes reverted: r212500, r212317, r212290.
llvm-svn: 212543
The purpose of the OptionValidator is to determine, based on some
arbitrary set of conditions, whether or not a command option is
valid for a given debugger state. An example of this might be
to selectively disable or enable certain command options that
don't apply to a particular platform.
This patch contains no functional change, and does not actually
make use of an OptionValidator for any purpose yet. A follow-up
patch will begin to add the logic and users of OptionValidator.
Reviewed by: Greg Clayton, Jim Ingham
Differential Revision: http://reviews.llvm.org/D4369
llvm-svn: 212290
Windows does support pipes, but they do so in a slightly different way. Added a Host layer which abstracts the use of pipes into a new Pipe class that everyone can use.
Windows benefits include:
- Being able to interrupt running processes when IO is directly hooked up
- being able to interrupt long running python scripts
- being able to interrupt anything based on ConnectionFileDescriptor
llvm-svn: 212220
This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64.
(More architectures coming soon).
Not every debugserver option is covered yet. Currently
the lldb-gdbserver command line can start unattached,
start attached to a pid (process-name attach not supported yet),
or accept lldb attaching and launching a process or connecting
by process id.
The history of this large change can be found here:
https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64
Until mid/late April, I was not sharing the work and continued
to rebase it off of head (developed via id tfiala@google.com). I switched over to
user todd.fiala@gmail.com in the middle, and once I went to github, I did
merges rather than rebasing so I could share with others.
llvm-svn: 212069
Elevate ProcessInfo and ProcessLaunchInfo into their own headers.
llgs will be using ProcessLaunchInfo but doesn't need to pull in
the rest of Process.h.
This also moves a bunch of implementation details from the header
declarations into ProcessInfo.cpp and ProcessLaunchInfo.cpp.
Tested on Ubuntu 14.04 Cmake and MacOSX Xcode.
Related to https://github.com/tfiala/lldb/issues/26.
llvm-svn: 212005
Add a callback that will allow an expression to be cancelled between the
expression evaluation stages (for the ClangUserExpressions.)
<rdar://problem/16790467>, <rdar://problem/16573440>
llvm-svn: 207944
- CTRL+C wasn't clearing the command in lldb
- CTRL+C doesn't work in python macros in lldb
- Ctrl+C no longer interrupts the running process that you attach to
<rdar://problem/15949205>
<rdar://problem/16778652>
<rdar://problem/16774411>
llvm-svn: 207816
but by the time we go to halt, it has already stopped by hitting the
function end breakpoint. That wasn't being shown to the threads so the
Function call thread plan didn't know its job was done.
<rdar://problem/16515785>
llvm-svn: 205803
This is a purely mechanical change explicitly casting any parameters for printf
style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux.
llvm-svn: 205607
Shawn Best