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
This change does the following:
* Adds Makefile build scripts to debug server.
* Fixes a few small mistakes in the other makefiles.
* Modifies generate-vers.pl slightly to also work for debugserver.
* Changes the OS X, non-framework python search path from libdir to
libdir/python2.X/site-packages where it is installed by the build
system (also where it is installed on other operating systems).
Patch by Keno Fischer.
llvm-svn: 199543
ArchSpec now contains an optional distribution_id, with getters and
setters. Host::GetArchitecture () sets it on non-Apple platforms using
Host::GetDistributionId (). The distribution_id is ignored during
ArchSpec comparisons.
The gdb remote qHostInfo message transmits it, if set, via the
distribution_id={id-value} key/value pair. Updated gdb remote docs to
reflect this change.
As before, GetDistributionId () returns nothing on non-Linux platforms
at this time. On Linux, it is returned only if the lsb_platform
command is installed (in /bin or /usr/bin), and only if the
distributor id key is returned by 'lsb_platform -i'. This id is
lowercased, and whitespace is replaced with underscores.
llvm-svn: 199539
The Linux distribution will be added to the ArchSpec class in an
upcoming change. This change only undoes the change to the triple. The
distribution retrieval logic and enabling of lldb-gdbserver for linux
x86_64 builds is still in place.
llvm-svn: 199520
This change does the following:
* enables building lldb-gdbserver on linux_x86-64 platforms.
Note - it builds but it has several run-time issues where many gdb
remote protocol features are not properly implemented yet. I'm
working on these one at a time.
* lldb-gdbserver: does not enable the eLaunchFlagDebug launch flag on
Linux. Currently the POSIX launch routine will assert if that flag
is passed in, presumably because that launch mode is not yet
available. This prevents lldb-gdbserver from asserting the moment
it launches the debuggee process.
* Adds ConstString& Host::GetDistributionId ()
This method is defined to return an empty result on all platforms
except for Linux. On Linux, it makes one attempt to execute
'lsb_release -i' (both /usr/bin/lsb_release, where it appears
on ubuntu, and /bin/lsb_release, where it appears on fedora
if the redhat-lsb package is installed). If lsb_release is not
found in either of those locations, or if 'lsb_release -i' does
not return the first line starting with "Distributor ID:\t",
then the distribution id is empty. The method will lower-case
the id and replace whitespace with underscores.
* Modify Host::GetArchitecture () so that linux replaces an unknown
vendor portion with the results of GetDistributionId () if that
is non-empty. This shows up now in qHostInfo remote packet
responses and on the lldb host side. Tested with ubuntu and
fedora (the latter both with the default of not having lsb_release
installed, and with having lsb_release installed via the redhat-lsb
package).
Examples of triples on Linux after this change:
# x86_64 Unbuntu 12.04 LTS:
x86_64-ubuntu-linux-gnu
# x86_64 Fedora 20 Desktop with redhat-lsb package installed
x86_64-fedora-linux-gnu
# x86_64 Fedora 20 Desktop without redhat-lsb-core installed
# (i.e. no /bin/lsb_release available)
# same as before the change
x86_64--linux-gnu
Note I intend to have Android respond with:
{arch}-android-linux
when I get to implementing Android lldb-gdbserver support.
llvm-svn: 199510
This rename was suggested by gclayton as a way to silence gcc
warnings; the warning is emitted when there is an overloaded function
in a base class (Platform) for which a derived class redefines one of
the overloads but not the other (because doing so hides the other
overload from users of the derived class). By giving the two methods
different names, the situation is avoided.
llvm-svn: 199504
Part 1 changes PlatformLinux::CreateInstance to always create with
is_host=false; that method is only used as the plug-in creator method
associated with the remote-linux platform plugin, and should therefore
always be remote.
Part 1 patch by Steve Pucci.
Part 2: fix a test break on linux.
In test/functionalities/thread/thread_specific_break, when using gcc,
either C99 mode would need to be enabled, or the code would need to
change. I changed a couple loop variable definitions to conform
to pre-C99 to simplify testing the fix. The second issue was
the necessity to include -lpthread as a linker option in the Makefile.
Any issues with that part are due to me (Todd Fiala).
llvm-svn: 199426
control to the user anyway. This was put in to handle monitors that would say there was no
stop reason when you first attached to them. But it broke the case where you hit a thread specific
breakpoint on many threads, but NOT the one specified in the breakpoint. I work around this
by only doing the junky override when the StopID is 0 - i.e. on first attach.
This commit also adds a test for thread specific breakpoints.
llvm-svn: 199290
As done in other DW_OP_* cases, return an error if the stack is empty
rather than eventually crashing elsewhere. Encountered on big-endian
MIPS, where LLVM bugs currently result in invalid .debug_loc data.
llvm-svn: 199110
symbols correctly. There were a couple of pieces to this.
1) When a breakpoint location finds itself pointing to an Indirect symbol, when the site for it is created
it needs to resolve the symbol and actually set the site at its target.
2) Not all breakpoints want to do this (i.e. a straight address breakpoint should always set itself on the
specified address, so somem machinery was needed to specify that.
3) I added some info to the break list output for indirect symbols so you could see what was happening.
Also I made it clear when we re-route through re-exported symbols.
4) I moved ResolveIndirectFunction from ProcessPosix to Process since it works the exact same way on Mac OS X
and the other posix systems. If we find a platform that doesn't do it this way, they can override the
call in Process.
5) Fixed one bug in RunThreadPlan, if you were trying to run a thread plan after a "running" event had
been broadcast, the event coalescing would cause you to miss the ThreadPlan running event. So I added
a way to override the coalescing.
6) Made DynamicLoaderMacOSXDYLD::GetStepThroughTrampolinePlan handle Indirect & Re-exported symbols.
<rdar://problem/15280639>
llvm-svn: 198976
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
210: test_with_dsym_and_run_command (Test-rdar-10642615.Radar10642615DataFormatterTestCase)
Test data formatter commands. ... Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file llvm/include/llvm/Support/Casting.h, line 239.
226: test_with_dsym_and_run_command (Test-rdar-13338477.Radar13338477DataFormatterTestCase)
Test that LLDB handles the clang typeclass Paren correctly. ... Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file llvm/include/llvm/Support/Casting.h, line 239.
llvm-svn: 198811
it is causing an llvm assert when run against
test/functionalities/data-formatter/rdar-10642615,
Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file llvm/include/llvm/Support/Casting.h, line 239.
llvm-svn: 198809
Ed Maste