This makes sure that nothing that requires Python is being built
when the LLDB_DISABLE_PYTHON flag is being passed in.
It also changes a use of CPPFLAGS to CPP.Flags since the former is overridden
when external flags are passed in while the later is not. I'm not sure exactly
why LLDB_DISABLE_PYTHON is in CXXFLAGS rather than CPPFLAGS,
but cleaning that up is for another commit.
Differential Revision: http://reviews.llvm.org/D4918
llvm-svn: 217414
This cleans up a couple of warnings [-Wcovered-switch-default] from the build by
removing the default case from a couple of switches which are fully covered.
This is generally better as it will help identify when a new item is added to
the enumeration but the use sites are not updated.
llvm-svn: 217376
This adds a definition for the TypeValidatorImpl_CXX destructor. Because the
destructor is first virtual method, and declared out-of-line, it also serves as
the key function. Since no definition was present, no virtual table for
TypeValidatorImpl_CXX was emitted, which results in link failures due to
references to undefined symbols.
Also add a definition for a TypeValidatorImpl contructor which was declared
out-of-line and referenced in a constructor for TypeValidatorImpl_CXX.
llvm-svn: 217375
Covers more of the behavior of rendezvous breakpoint handling and other
dynamic loader aspects, all on the 'enable log lldb dyld' log channel.
llvm-svn: 217283
Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents
For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light
This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators
It also lacks the notion of Python validators
llvm-svn: 217277
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
detct unwind loops but there was a code path through there (using
architecture default unwind plans) that didn't do the check, and
could end up with an infinite loop unwind. Move that code into a
separate method and call it from both places where it is needed.
Also remove the use of ABI::FunctionCallsChangeCFA in that check.
I thought about it a lot and none of the architecutres that we're
supporting today can have a looping CFA.
Since the unwinder isn't using ABI::FunctionCallsChangeCFA() and
ABI::StackUsesFrames(), and the unwinder was the only reason
those methods exists, I removed them from the ABI and all its
plugins.
<rdar://problem/17364005>
llvm-svn: 216992
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 patch accepts environment variables of the form:
LLDB_DEBUGSERVER_EXTRA_ARG_n
where n starts with 1, and may continue nearly indefinitely (up through std::numeric_limits<uint32_t>::max()).
The code loops around, starting with 1, until it doesn't find one of the environment variables. For each one it does find defined, it appends the environment variable's contents to the end of the debugserver/llgs startup command line issued when the stub is started for local debugging.
I am using this to add arbitrary startup commands to the llgs command line for turning on additional logging. For example:
export LLDB_DEBUGSERVER_EXTRA_ARG_1="-c"
export LLDB_DEBUGSERVER_EXTRA_ARG_2="log enable -f /tmp/llgs_packets.log gdb-remote packets"
export LLDB_DEBUGSERVER_EXTRA_ARG_3="-c"
export LLDB_DEBUGSERVER_EXTRA_ARG_4="log enable -f /tmp/llgs_process.log lldb process"
llvm-svn: 216745
Yet another step toward ARM64 support. With this commit, lldb-gdbserver started on ARM64 target can be accessed by lldb running on desktop PC and it can process simple commands (like 'continue'). Still ARM64 support lacks NativeRegisterContextLinux_arm64.* code which waits to be implemented.
Based on similar files for Linux x86_64 and Darwin ARM64. Due to common code extraction from Darwin related files, lldb should be tested for any unexpected regression on Darwin ARM64 machines too.
See the following for more details:
http://reviews.llvm.org/D4580http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140825/012670.html
Change by Paul Osmialowski.
llvm-svn: 216737
For hosts that cannot support long thread names, shrink the host
wait4 thread name so that it does not truncate the PID in the thread name.
Change by Shawn Best.
llvm-svn: 216686
This change:
* properly captures execs in NativeProcessLinux.
* clears out all non-main-thread thread metadata in NativeProcessLinux on exec.
* adds a DidExec() method to the NativeProcessProtocol delegate.
* clears out the auxv data cache when we exec (on Linux).
This is a small part of the llgs for local Linux debugging work going on here:
https://github.com/tfiala/lldb/tree/dev-llgs-local
I'm breaking it into small patches.
llvm-svn: 216670
This is a lightweight wrapper around a pid. It is intended to be
lightweight enough to serve as a replacement anywhere we currently
store a pid. It provides convenience methods and common process
operations.
This patch does not yet make use of HostProcess anywhere.
llvm-svn: 216607
LLDB had implemented its own DynamicLibrary class for plugin
support. LLVM has an equivalent mechanism, so this patch deletes
the duplicated code in LLDB and updates LLDB to reference the
mechanism provided by LLVM.
llvm-svn: 216606
Keno Fischer