Summary:
This should solve the issue of sending denormalized paths over gdb-remote
if we stick to GetPath(false) in GDBRemoteCommunicationClient, and let the
server handle any denormalization.
Reviewers: ovyalov, zturner, vharron, clayborg
Reviewed By: clayborg
Subscribers: tberghammer, emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D9728
llvm-svn: 238604
Since interaction with the python interpreter is moving towards
being more isolated, we won't be able to include this header from
normal files anymore, all includes of it should be localized to
the python library which will live under source/bindings/API/Python
after a future patch.
None of the files that were including this header actually depended
on it anyway, so it was just a dead include in every single instance.
llvm-svn: 238581
Summary:
IOHandlerProcessSTDIO::Run() was opening the pipe for interrupt requests lazily. This was racing
with another thread executing IOHandlerProcessSTDIO::Cancel() simultaneously. I fix this by
opening the pipe in the object constructor. The pipe will be automatically closed when the object
is destroyed.
Test Plan: Tests pass on linux.
Reviewers: clayborg, ribrdb
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10060
llvm-svn: 238423
This was the original cause of the file descriptor leaks that would cause the test suite to die after running a few hundred processes since no process would ever get destroyed and the communication channel in ProcessGDBRemote and the ProcessIOHandler would never close their pipes.
This process leak was previously worked around by closing the pipes when the communication channel was disconnected.
This was found by using "ptr_refs" from the heap.py in the lldb.macosx.heap module. It was able to find all strong references to the Process and helped me to figure out who was holding this extra reference.
llvm-svn: 238392
Summary:
There is an issue in lldb where the command prompt can appear at the wrong time. The partial fix
we have in for this is not working all the time and is introducing unnecessary delays. This
change does:
- Change Process:SyncIOHandler to use integer start id's for synchronization to avoid it being
confused by quick start-stop cycles. I picked this up from a suggested patch by Greg to
lldb-dev.
- coordinates printing of asynchronous text with the iohandlers. This is also based on a
(different) Greg's patch, but I have added stronger synchronization to it to avoid races.
Together, these changes solve the prompt problem for me on linux (both with and without libedit).
I think they should behave similarly on Mac and FreeBSD and I think they will not make matters
worse for windows.
Test Plan: Prompt comes out alright. All tests still pass on linux.
Reviewers: clayborg, emaste, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9823
llvm-svn: 238313
The main issue was the Communication::Disconnect() was calling its Connection::Disconnect() but this wouldn't release the pipes that the ConnectionFileDescriptor was using. We also have someone that is holding a strong reference to the Process so that when you re-run, target replaces its m_process_sp, but it doesn't get destructed because someone has a strong reference to it. I need to track that down. But, even if we have a strong reference to the a process that is outstanding, we need to call Process::Finalize() to have it release as much of its resources as possible to avoid memory bloat.
Removed the ProcessGDBRemote::SetExitStatus() override and replaced it with ProcessGDBRemote::DidExit().
Now we aren't leaking file descriptors and the stand alone test suite should run much better.
llvm-svn: 238089
the changes in r233255/r233258. Normally if lldb attaches to
a running process, when we call Process::Destroy, we want to detach
from the process. If lldb launched the process itself, ::Destroy
should kill it.
However, if we attach to a process and the driver calls SBProcess::Kill()
(which calls Destroy), we need to kill it even if we didn't launch it
originally.
The force_kill param allows for the SBProcess::Kill method to force the
behavior of Destroy.
<rdar://problem/20424439>
llvm-svn: 235158
virtual void
LanguageRuntime::ModulesDidLoad (const ModuleList &module_list);
Then reorganized how the objective C plug-in is notified so it will work for all LanguageRuntime subclasses.
llvm-svn: 235118
There were a couple of real bugs here regarding error checking and
signed/unsigned comparisons, but mostly these were just noise.
There was one class of bugs fixed here which is particularly
annoying, dealing with MSVC's non-standard behavior regarding
the underlying type of enums. See the comment in
lldb-enumerations.h for details. In short, from now on please use
FLAGS_ENUM and FLAGS_ANONYMOUS_ENUM when defining enums which
contain values larger than can fit into a signed integer.
llvm-svn: 233943
Guard against this by setting a new "m_finalizing" flag that lets us know we are in the process of finalizing.
<rdar://problem/20369152>
llvm-svn: 233935
Summary:
This patch fixes -gdb-exit for locally target. It includes the following changes:
# Fix Process::Finalize
# Use SBProcess::Destroy in -gdb-exit
Reviewers: abidh, zturner, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits, clayborg, abidh
Differential Revision: http://reviews.llvm.org/D8298
llvm-svn: 233255
Previously the remote module sepcification was fetched only from the
remote platform. With this CL if we have a remote process then we ask it
if it have any information from a given module. It is required because
on android the dynamic linker only reports the name of the SO file and
the platform can't always find it without a full path (the process can
do it based on /proc/<pid>/maps).
Differential revision: http://reviews.llvm.org/D8547
llvm-svn: 233061
Specifically, there were some functions for converting enums
to strings and a function for matching a string using a specific
matching algorithm. This moves those functions to more appropriate
headers in lldb/Utility and updates references to include the
new headers.
llvm-svn: 232673
So that we don't have to update every single #include in the entire
codebase to #include this new header (which used to get included by
lldb-private-log.h, we automatically #include "Logging.h" from
within "Log.h".
llvm-svn: 232653
# Fix CommandInterpreter.Broadcaster name (it should be the same as CommandInterpreter::GetStaticBroadcasterClass())
# Prevent the same error in Process.Broadcaster
# Fix SBCommandInterpreter::GetBroadcasterClass (it should call CommandInterpreter::GetStaticBroadcasterClass(), was Communication::GetStaticBroadcasterClass())
llvm-svn: 232500
Summary:
There was a race condition regarding the output of the inferior process. The reading of the
output is performed on a separate thread, and there was no guarantee that the output will get
eventually consumed. Because of that, it was happening that calling Process::GetSTDOUT was not
returning anything even though the process was terminated and would definitely not produce any
further output. This was usually happening only under very heavy system load, but it can be
reproduced by placing an usleep in the stdio thread (Process::STDIOReadThreadBytesReceived).
This patch addresses this by adding synchronization capabilities to the Communication thread.
After calling Communication::SynchronizeWithReadThread one can be sure that all pending input has
been processed by the read thread. This function is then called after every public event which
stops the process to obtain the entire process output.
Test Plan: TestProcessIO.py should now succeed every time instead of flaking in and out.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8246
llvm-svn: 232023
Summary:
starting a debug session on linux with -o "process launch" lldb parameter was failing since
Target::Launch (in sychronous mode) is expecting to be able to receive public process events.
However, PlatformLinux did not set up event hijacking on process launch, which caused these
events to be processed elsewhere and left Target::Launch hanging. This patch enables event
interception in PlatformLinux (which was commented out).
Upon enabling event interception, I noticed an issue, which I traced back to the inconsistent
state of public run lock, which remained false even though public and private process states were
"stopped". I addressed this by making sure the run lock is "stopped" upon exit from
WaitForProcessToStop (which already had similar provisions for other return paths).
Test Plan: This should fix the intermittent TestFormats failure we have been experiencing on Linux.
Reviewers: jingham, clayborg, vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8079
llvm-svn: 231460
Earlier this week I was able to get clang-cl on Windows to be
able to self host. This opened the door to being able to
get a whole new slew of warnings for the Windows build.
This patch fixes all of the warnings, many of which were real
bugs.
llvm-svn: 230522
Process::Launch try to catch a stop signal after launching a process. If
it is unsuccessful it destroy the process but previously still reported
that the process launched successfully. This behavior caused a
deadlock. With thic change the process launch error reported correctly.
Differential revision: http://reviews.llvm.org/D7784
llvm-svn: 230212
We want to forward stdin when stdio is not disabled and when we're not
redirecting stdin from a file.
renamed m_stdio_disable to m_stdin_forward and inverted value because
that's what we want to remember.
There was previously a bug that if you redirected stdin from a file,
stdout and stderr would also be redirected to /dev/null
Adds support for remote target to TestProcessIO.py
Fixes ProcessIOTestCase.test_stdin_redirection_with_dwarf for remote
Linux targets
llvm-svn: 228744
Processes running on a remote target can already send $O messages
to send stdout but there is no way to send stdin to a remote
inferior.
This allows processes using the API to pump stdin into a remote
inferior process.
It fixes a hang in TestProcessIO.py when running against a remote
target.
llvm-svn: 228419
Summary:
This patch fixes *stopped notification for remote target when started with eLaunchFlagStopAtEntry (for example, using "process launch -s").
See explanation below:
```
Target::Launch (ProcessLaunchInfo &launch_info, Stream *stream)
{
...
if (state != eStateConnected && platform_sp && platform_sp->CanDebugProcess ())
{
...
}
else
{
...
if (m_process_sp)
error = m_process_sp->Launch (launch_info);
}
if (error.Success())
{
if (launch_info.GetFlags().Test(eLaunchFlagStopAtEntry) == false)
{
....
}
-- missing event if eLaunchFlagStopAtEntry is set --
m_process_sp->RestoreProcessEvents ();
}
...
return error
```
Also this patch contains tests and you can check how it works.
Reviewers: zturner, clayborg, abidh
Reviewed By: clayborg
Subscribers: clayborg, abidh, zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D7273
llvm-svn: 228417
CommandInterpreter's execution context AFTER the process had started running
and before it initially stopped. Also fixed one test case that was implicitly
using this (and an abuse of the async mode) to accidentally succeed.
<rdar://problem/16814726>
llvm-svn: 226528
This is currently controlled by a setting:
(lldb) settings set target.process.python-os-plugin-path <path>
Or clearing it with:
(lldb) settings clear target.process.python-os-plugin-path
The process will now reload the OperatingSystem plug-in.
This was implemented by:
- adding the ability to set a notify callback for when an option value is changed
- added the ability for the process plug-in to load the operating system plug-in on the fly
- fixed bugs in the Process::GetStatus() so all threads are displayed if their thread IDs are larger than 32 bits
- adding a callback in ProcessProperties to tell when the "python-os-plugin-path" is changed by the user
- fixing a crasher in ProcessMachCore that happens when updating the thread list when the OS plugin is reloaded
llvm-svn: 225831
This patch makes a number of improvements to the Pipe interface.
1) An interface (PipeBase) is provided which exposes pure virtual
methods for any implementation of Pipe to override. While not
strictly necessary, this helps catch errors where the interfaces
are out of sync.
2) All methods return lldb_private::Error instead of returning bool
or void. This allows richer error information to be propagated
up to LLDB.
3) A new ReadWithTimeout() method is exposed in the base class and
implemented on Windows.
4) Support for both named and anonymous pipes is exposed through the
base interface and implemented on Windows. For creating a new
pipe, both named and anonymous pipes are supported, and for
opening an existing pipe, only named pipes are supported.
New methods described in points #3 and #4 are stubbed out on posix,
but fully implemented on Windows. These should be implemented by
someone on the linux / mac / bsd side.
Reviewed by: Greg Clayton, Oleksiy Vyalov
Differential Revision: http://reviews.llvm.org/D6686
llvm-svn: 224442
Summary:
If a stream contains an empty string, no need to append it to the output
(otherwise we end up with a blank line). Also, no need to print a status
message when the state changes to connected, as this string brings no
information -- "Process 0" does not mean anything to the user, and the
process being connected has no meaning either.
Test Plan:
Connect to a remote linux platform mode daemon with `platform select
remote-linux` followed by `platform connect ...`, create a target and
run it, observe the output. Also, run the full test suite (dosep.py).
Before:
(lldb) [...] connect, etc.
(lldb) r
Process 0 connected
Process 5635 launched: '/Users/sas/Source/test' (x86_64)
Process 5635 stopped
After:
(lldb) [...] connect, etc.
(lldb) r
Process 5635 launched: '/Users/sas/Source/test' (x86_64)
Process 5635 stopped
Reviewers: tfiala, vharron, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6593
llvm-svn: 224188
The issue with Thumb IT (if/then) instructions is the IT instruction preceeds up to four instructions that are made conditional. If a breakpoint is placed on one of the conditional instructions, the instruction either needs to match the thumb opcode size (2 or 4 bytes) or a BKPT instruction needs to be used as these are always unconditional (even in a IT instruction). If BKPT instructions are used, then we might end up stopping on an instruction that won't get executed. So if we do stop at a BKPT instruction, we need to continue if the condition is not true.
When using the BKPT isntructions are easy in that you don't need to detect the size of the breakpoint that needs to be used when setting a breakpoint even in a thumb IT instruction. The bad part is you will now always stop at the opcode location and let LLDB determine if it should auto-continue. If the BKPT instruction is used, the BKPT that is used for ARM code should be something that also triggers the BKPT instruction in Thumb in case you set a breakpoint in the middle of code and the code is actually Thumb code. A value of 0xE120BE70 will work since the lower 16 bits being 0xBE70 happens to be a Thumb BKPT instruction.
The alternative is to use trap or illegal instructions that the kernel will translate into breakpoint hits. On Mac this was 0xE7FFDEFE for ARM and 0xDEFE for Thumb. The darwin kernel currently doesn't recognize any 32 bit Thumb instruction as a instruction that will get turned into a breakpoint exception (EXC_BREAKPOINT), so we had to use the BKPT instruction on Mac. The linux kernel recognizes a 16 and a 32 bit instruction as valid thumb breakpoint opcodes. The benefit of using 16 or 32 bit instructions is you don't stop on opcodes in a IT block when the condition doesn't match.
To further complicate things, single stepping on ARM is often implemented by modifying the BCR/BVR registers and setting the processor to stop when the PC is not equal to the current value. This means single stepping is another way the ARM target can stop on instructions that won't get executed.
This patch does the following:
1 - Fix the internal debugserver for Apple to use the BKPT instruction for ARM and Thumb
2 - Fix LLDB to catch when we stop in the middle of a Thumb IT instruction and continue if we stop at an instruction that won't execute
3 - Fixes this in a way that will work for any target on any platform as long as it is ARM/Thumb
4 - Adds a patch for ignoring conditions that don't match when in ARM mode (see below)
This patch also provides the code that implements the same thing for ARM instructions, though it is disabled for now. The ARM patch will check the condition of the instruction in ARM mode and continue if the condition isn't true (and therefore the instruction would not be executed). Again, this is not enable, but the code for it has been added.
<rdar://problem/19145455>
llvm-svn: 223851
Fixed include:
- Change Platform::ResolveExecutable(...) to take a ModuleSpec instead of a FileSpec + ArchSpec to help resolve executables correctly when we have just a path + UUID (no arch).
- Add the ability to set the listener in SBLaunchInfo and SBAttachInfo in case you don't want to use the debugger as the default listener.
- Modified all places that use the SBLaunchInfo/SBAttachInfo and the internal ProcessLaunchInfo/ProcessAttachInfo to not take a listener as a parameter since it is in the launch/attach info now
- Load a module's sections by default when removing a module from a target. Since we create JIT modules for expressions and helper functions, we could end up with stale data in the section load list if a module was removed from the target as the section load list would still have entries for the unloaded module. Target now has the following functions to help unload all sections a single or multiple modules:
size_t
Target::UnloadModuleSections (const ModuleList &module_list);
size_t
Target::UnloadModuleSections (const lldb::ModuleSP &module_sp);
llvm-svn: 222167
Improvements include:
* Use of libedit's wide character support, which is imperfect but a distinct improvement over ASCII-only
* Fallback for ASCII editing path
* Support for a "faint" prompt clearly distinguished from input
* Breaking lines and insert new lines in the middle of a batch by simply pressing return
* Joining lines with forward and backward character deletion
* Detection of paste to suppress automatic formatting and statement completion tests
* Correctly reformatting when lines grow or shrink to occupy different numbers of rows
* Saving multi-line history, and correctly preserving the "tip" of history during editing
* Displaying visible ^C and ^D indications when interrupting input or sending EOF
* Fledgling VI support for multi-line editing
* General correctness and reliability improvements
llvm-svn: 222163
There were many issues with synchronous mode that we discovered when started to try and add a "batch" mode. There was a race condition where the event handling thread might consume events when in sync mode and other times the Process::WaitForProcessToStop() would consume them. This also led to places where the Process IO handler might or might not get popped when it needed to be.
llvm-svn: 220254
an uninitialized value. In reality the code block that
initializes it and the code block that restores it will always
match up - but the analyzer doesn't know that and I want to
quiet it, so...
clang static analyzer fixit.
llvm-svn: 219869
Reviewed at http://reviews.llvm.org/D5738
This adds an SB API into SBProcess:
bool SBProcess::IsInstrumentationRuntimePresent(InstrumentationRuntimeType type);
which simply tells whether a particular InstrumentationRuntime (read "ASan") plugin is present and active.
llvm-svn: 219560
Reviewed at http://reviews.llvm.org/D5592
This patch gives LLDB some ability to interact with AddressSanitizer runtime library, on top of what we already have (historical memory stack traces provided by ASan). Namely, that's the ability to stop on an error caught by ASan, and access the report information that are associated with it. The report information is also exposed into SB API.
More precisely this patch...
adds a new plugin type, InstrumentationRuntime, which should serve as a generic superclass for other instrumentation runtime libraries, these plugins get notified when modules are loaded, so they get a chance to "activate" when a specific dynamic library is loaded
an instance of this plugin type, AddressSanitizerRuntime, which activates itself when it sees the ASan dynamic library or founds ASan statically linked in the executable
adds a collection of these plugins into the Process class
AddressSanitizerRuntime sets an internal breakpoint on __asan::AsanDie(), and when this breakpoint gets hit, it retrieves the report information from ASan
this breakpoint is then exposed as a new StopReason, eStopReasonInstrumentation, with a new StopInfo subclass, InstrumentationRuntimeStopInfo
the StopInfo superclass is extended with a m_extended_info field (it's a StructuredData::ObjectSP), that can hold arbitrary JSON-like data, which is the way the new plugin provides the report data
the "thread info" command now accepts a "-s" flag that prints out the JSON data of a stop reason (same way the "-j" flag works now)
SBThread has a new API, GetStopReasonExtendedInfoAsJSON, which dumps the JSON string into a SBStream
adds a test case for all of this
I plan to also get rid of the original ASan plugin (memory history stack traces) and use an instance of AddressSanitizerRuntime for that purpose.
Kuba
llvm-svn: 219546
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
Chaoren Lin