Need to spend a little more time with suppressing the debugserver 64-to-32 bit warnings.
Will re-submit after I get the warnings properly suppressed.
llvm-svn: 209151
debugserver now returns $X09 as the immediate response to
a $k kill process request rather than $W09.
ProcessGDBRemote now properly handles X as indication of
a process exit state.
The @debugserver_test and @lldb_test for $k now properly expects
an X notification (signal-caused exit) after killing a just-attached
inferior that was still in the stopped state.
llvm-svn: 209108
- Tested with Eclipse, likely to work with other GDB/MI compatible GUIs.
- Some but not all MI commands have been implemented. See MIReadme.txt for more info.
- Written from scratch, no GPL code, based on LLDB Public API.
- Built for Linux, Windows and OSX. Tested on Linux and Windows.
- GDB/MI Command Reference, https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI.html
llvm-svn: 208972
$qC from debugserver now returns the current thread's thread-id (and, like $?, will set a current thread if one is not already selected). Previously it was returning the current process id.
lldb will now query $qProcessInfo to retrieve the process id. The process id is now cached lazily and reset like other cached values. Retrieval of the process id will fall back to the old $qC method for vendor==Apple and os==iOS if the qProcessInfo retrieval fails.
Added a gdb remote protocol-level test to verify that $qProcessInfo reports a valid process id after launching a process, while the process is in the initial stopped state. Verifies the given process id is a currently valid process on host OSes for which we know how to check (MacOSX, Linux, {Free/Net}BSD). Ignores the live process check for OSes where we don't know how to do this. (I saw no portable way to do this in stock Python without pulling in other libs).
llvm-svn: 208241
This now builds lldb-gdbserver on all Linux and FreeBSD architectures
rather than being locked to x86_64 architectures only.
Please note lldb-gdbserver is not yet functional, this just enables
the non-x86_64 Linux/FreeBSD build using the configure/make build
system.
--This line, and
those below, will be ignored--
M tools/Makefile
llvm-svn: 207556
These changes were written by Greg Clayton, Jim Ingham, Jason Molenda.
It builds cleanly against TOT llvm with xcodebuild. I updated the
cmake files by visual inspection but did not try a build. I haven't
built these sources on any non-Mac platforms - I don't think this
patch adds any code that requires darwin, but please let me know if
I missed something.
In debugserver, MachProcess.cpp and MachTask.cpp were renamed to
MachProcess.mm and MachTask.mm as they picked up some new Objective-C
code needed to launch processes when running on iOS.
llvm-svn: 205113
condition where we could end up killing debugserver (and thus the target) before it had a chance
to detach.
Also fix debugserver to send the OK AFTER it detaches to avoid the same race condition.
<rdar://problem/16202713>
llvm-svn: 205043
1 - There were some outdated options being passed to clang
2 - There were some bad paths being passed as options
3 - The path to the main.cpp file ("/tmp/main.cpp") was wrong when the tests were being run, now we create a temp file
4 - Added a new ActionType::eNone to do nothing (no continue, step, or kill)
llvm-svn: 202431
Also fix the bug where lldb prints: "Got a connection and launched debugserver" rather
than the name of the process it actually launched.
llvm-svn: 202189
GDBProcessCommunicationServer now optionally takes a PlatformSP that
defaults to the default platform for the host.
GDBProcessCommunicationServer::LaunchProcess () now uses the platform
to launch the process.
lldb-gdbserver now takes an optional --platform={platform_plugin_name}
or -p {platform_plugin_name} command line option. If no platform is
specified, the default platform for the host is used; otherwise, if
the platform_plugin_name matches a registered platform plugin or
matches the default platform's name (which is not necessarily
registered by name in the case of 'host'), that platform is used. If
the platform name cannot be resolved, lldb-gdbserver exits after
printing all the available platform plugin names and the default
platform plugin name.
llvm-svn: 200266
The many many benefits include:
1 - Input/Output/Error streams are now handled as real streams not a push style input
2 - auto completion in python embedded interpreter
3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use
4 - it is now possible to use curses to drive LLDB (please try the "gui" command)
We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases.
llvm-svn: 200263
GDBRemoteCommunicationServer::LaunchProcess () now uses the built-up
ProcessLaunchArgs rather than clearing and setting items from the
function arguments. I added setters for the arguments and launch
flags, which lldb-gdbserver uses for its specification of the
commandline-specified startup app (if one is specified).
LaunchProcess () also adds a new reaper monitor that it applies to
the launched process if no process monitor has already been applied.
This addresses an issue where the 'k' command would generate (possibly
false) warnings about not being able to positively state whether a
killed process actually terminated. GDBRemoteCommunicationServer now
definitely knows the disposition of its children.
llvm-svn: 199959
lldb-gdbserver was launching the commandline-specified launch process
directly, without GDBRemoteCommunicationServer knowing anything about
it. As GDBRemoteCommunicationServer is the piece that manages and
knows about processes that the gdb remote protocol discusses with
the client end, it is important that it know about launched processes.
This change also implements the k gdb remote protocol message, having it
kill all known spawned processes when it is received.
(Note: in lldb-gdbserver, the spawned processes are not properly
monitored yet. The response to the k packet will complain that
spawned processes do not really appear to be getting killed even if
they are. This will get addressed soon.)
llvm-svn: 199945
lldb-gdbserver now takes zero or more --lldb-command {command} options
that get executed by the command interpreter prior to starting up
a child debuggee process. The short form is -c {command}. This is
similar to how lldb-platform works.
This command can be used to enable logging in more than just the
gdb-remote log channel. Here is an example startup sequence that allows
logging of lldb host and process log categories to one file and
gdb-remote packets to another file:
lldb-gdbserver -c 'log enable -f lgs.log lldb process host' \
-c 'log enable -f lgs_packets.log gdb-remote packets' \
localhost:5432 ./some_exe
llvm-svn: 199761
