This could use some refinement still, but the previous behaviour of adding
-stdlib=libstc++ on FreeBSD w/ Clang is the least likely case to work.
llvm.org/pr17910
llvm-svn: 200646
Fixes http://llvm.org/bugs/show_bug.cgi?id=18656.
Note this exposes a failure on Linux of
TestInferiorAssert.test_inferior_asserting_disassemble, similar to how
it fails on FreeBSD. I'll file a bug for this next. We're now getting
another frame beyond where we used to prior to this fix, so the fix is
exposing failures in previosly not-reachable frames.
Much thanks to Jason Molenda, who had much to do with helping figure
out where unwinding was breaking.
llvm-svn: 200600
This change addresses shutdown crashes in the python lldb module when
the script interpreter was hanging on to saved file references after
leaving a session. It also gets rid of extra references to the
stdin/stdout/stderr python file objects that are created when entering
the session.
This change also moves the bundled pyexpect 2.4 library to the front
of the python library path so that a python distribution default
pyexpect (2.3 in Ubuntu 12.04) is not picked up first.
llvm-svn: 200486
PyTuple_SetItem steals a reference to the item it inserts in the tuple
This, plus the Py_XDECREF of the tuple a few lines below, causes our session dictionary to go away after the first time a SWIG layer function is called - with disastrous effects for the first subsequent attempt to use any functionality in ScriptInterpreterPython
This fixes it
llvm-svn: 200429
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
if the remote stub provided enough information to identify it in the
qProcessInfo packet response. (e.g. for an Apple device where we know
it is Mach-O, the cpu type & cpu sub type).
<rdar://problem/15847901>
llvm-svn: 200253
ValueObjectPrinter could enter an infinite loop while trying to display an aptly formed ValueObject: a reference, with a child of some pointer type, such that the pointees chain ended up pointing back to some part of itself - a pointer to itself being the simplest such case
Fixed here by only setting a pointer depth when needed, and ensuring that we won't overflow and wrap the pointer depth when it's zero.
llvm-svn: 200247
This change modifies the 'A' command handler's launch code to launch
with LaunchProcess (). The net effect is that the default process
monitoring that LaunchProcess () adds will kick in, allowing the
GDBRemoteCommunicationServer to be able to reap processes started with
this facility correctly. Later, in the case of lldb-gdbserver, we'll
also have the proper process monitoring going on to really debug the
inferior process.
llvm-svn: 200246
This patch addresses a bug where in a multi-threaded program a new
signal from the inferior may be received before all group-stop
messages from an earlier signal have been handled.
Patch by Andrew MacPherson
llvm-svn: 200226
There are a couple of pieces:
* some lazy-evaluation members that store info listed in a qSupported response
* new method SendPacketsAndConcatenateResponses which is used for
fetching fixed-size objects from the remote gdbserver by using multiple
packets if necessary (first use will be to fetch shared-library XML files).
llvm-svn: 200072
GetU32 and GetU64, to use memcpy to copy bytes into a local buffer instead
of having a (uint64_t *) etc local variable, pointing to the address, and
dereferencing it. If compiled on a CPU where data alignment is required
(e.g. the LDM instruction on armv7) and we try to GetU64 out of a mmap'ed
DWARF file, that 8 byte quantity may not be world aligned and the program
can get an unaligned memory access fault.
<rdar://problem/15849231>
llvm-svn: 200069
right after the space for it is allocated on the stack, instead of trying
to initialize it in all the different places in this method. It's too easy
for another uninitialized code path to sneak in as it is written right now.
llvm-svn: 200066
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
SBType SBType::GetTypedefedType();
Also added the ability to get a type by type ID from a SBModule:
SBType SBModule::GetTypeByID (lldb::user_id_t uid);
llvm-svn: 199939
This reverts Host.cpp LaunchProcess spawn behavior on FreeBSD to be
like Linux (and unlike OS X) with regards to how default signal
handlers and setup on the spawned process. FreeBSD does not reset
default signal handlers on the spawned process after this change.
llvm-svn: 199908
This fixes a bug under Linux where spawning a process via
Host::LaunchProcess was disabling all blockable signals on the
launched process. This caused strange behavior when attempting
to kill the lldb-gdbserver process, as the child generally would
not die unless killed with a non-blockable signal (e.g. 'kill -9').
This change moves several functions out of macosx/Host.mm into
common/Host.cpp. In addition, two functions that needed to work
across common/Host.cpp and macosx/Host.mm were moved into the Host.h
header file.
llvm-svn: 199856
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
Ed Maste