Any commands that want interactivity (stdin) will need to be executed through the normal command interpreter using the debugger's in/out/err file handles, or by using "command source".
Individual commands through the API will have their STDIN disabled. The STDOUT and STDERR will be redirected into the SBCommandReturnObject argument to SBCommandInterpreter::HandleCommand() as usual.
This helps with a deadlock situation in an IDE (Xcode) where the IDE was managing the breakpoint actions by setting a breakpoint callback and doing things manually.
<rdar://problem/17386271>
llvm-svn: 213023
Now that llgs supports communicating the 0-port choose-a-port
mechanism and can communicate that back to a caller via the
--named-pipe option (at parity with debugserver), we use this
mechanism to always start llgs and debugserver gdb-remote
protocol tests without needing to use some port arbitration
mechanism. This eliminates some potential intermittent failures vs. the
previous random port and collision-avoidance strategy used.
llvm-svn: 212923
This is the last flag sent by lldb-platform that was not accepted
by llgs and is accepted by debugserver.
Conditionalized out a bit more code in prep for Windows
support one day based on _WIN32 define.
Updated the lldb-gdbserver usage string to represent
recent updates to command line arguments (and some older
ones like --attach pid).
Implements https://github.com/tfiala/lldb/issues/37
llvm-svn: 212879
The testrun now completes successfully on my FreeBSD 11.0-CURRENT
laptop. There are some intermittent failures on the FreeBSD buildbot
still, which should be addressed in later commits.
llvm.org/pr20274
llvm-svn: 212878
The --setsid (-S) option changes the session id for the lldb-gdbserver process.
This is used by tools such as lldb-platform and allows the user to prevent
llgs from being in the same session as a calling terminal session.
This will prevents terminal group control signals from affecting
lldb-gdbserver.
See also:
https://github.com/tfiala/lldb/issues/38
llvm-svn: 212873
Added a unit test to test debugserver and llgs compliance on --named-pipe support.
Modified llgs to implement --named-pipe support. (Note: need to revisit with
new generic pipe support).
llvm-svn: 212854
The fix adds a std::weak_ptr<Module> into the TypeImpl and fills in the weak pointer when possible. It also checks to make sure the module is still alive prior to using it which should make our API safer to use.
<rdar://problem/15455145>
llvm-svn: 212853
If we have any section headers in the collection, we already parsed them.
Therefore, don't reparse the section headers when the section_headers collection
is not empty.
See this thread for more details:
http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140707/011721.html
Change by Matthew Gardiner
llvm-svn: 212822
This patch fixes a number of issues with embedded Python on
Windows. In particular:
1) The script that builds the python modules was normalizing the
case of python filenames during copies. The module name is
the filename, and is case-sensitive, so this was breaking code.
2) Changes the build to not attempt to link against python27.lib
(e.g. the release library) when linking against msvcrt debug
library. Doing a debug build of LLDB with embedded python
support now requires you to provide your own self-compiled
debug version of python.
3) Don't import termios when initializing the interpreter. This
is part of a larger effort to remove the dependency on termios
since it is not available on Windows. This particular instance
was unnecessary and unused.
Reviewed by: Todd Fiala
Differential Revision: http://reviews.llvm.org/D4441
llvm-svn: 212785
Fixes include:
- Don't say that "<arch>-apple-ios" is compatible with "<arch>-apple-macosx"
- Fixed DynamicLoaderMacOSXDYLD so specify an architecture that was converted solely from a cputype and subtype, just specify the file + UUID.
- Fixed PlatformiOSSimulator::GetSupportedArchitectureAtIndex() so it returns the correct archs
- Fixed SymbolFileDWARFDebugMap to load .o files correctly by just specifying the architecture without the vendor and OS now that "<arch>-apple-ios" is not compatible with "<arch>-apple-macosx" so we can load .o files correctly for DWARF with debug map
- Fixed the coded in TargetList::CreateTarget() so it does the right thing with an underspecified triple where just the arch is specified.
llvm-svn: 212783
The following intermittently-failing tests have been flipped from
skip to XFAIL on some combo of Linux and MacOSX:
TestCallStopAndContinue.py (Linux, MacOSX)
TestCallWithTimeout.py (Linux)
TestConvenienceVariables.py (Linux)
TestStopHookMultipleThreads.py (Linux)
The following new tests have been marked XFAIL but are just
intermittently failing:
TestMultipleDebug.py (definitely intermittent on MacOSX, not sure I've seen
it pass yet on Linux)
llvm-svn: 212762
Being in lldb\source, ${CMAKE_CURRENT_BINARY_DIR} would resolve to
the build\tools\lldb\source directory. For correct operation, and
parity with the shell script, it needs to resolve to the
build\tools\lldb\scripts directory.
llvm-svn: 212760
These fix the broken debian lldb build, which is using g++ 4.7.2.
TypeFormat changes:
1. stopped using the C++11 "dtor = default;" construct.
The generated default destructor in the two derived classes wanted
them to have a different throws() semantic that was causing 4.7 to
fail to generate it. I switched these to empty destructors defined
in the .cpp file.
2. Switched the m_types map from an ordered map to an unordered_map.
g++ 4.7's c++ library supports the C++11 emplace() used by TypeFormat
but the same c++ library's map impl does not. Since TypeFormat didn't
look like it depended on ordering in the map, I just switched it to
a std::unordered_map.
NativeProcessLinux - g++ 4.7 chokes on lexing the "<::" in
static_cast<::pid_t>(wpid). g++ 4.8+ and clang are fine with it.
I just put a space in between the "<" and the "::" and that cleared
it up.
llvm-svn: 212681
debug sessions simultaneously to expose race conditoin/locking
issues.
This directory has an inferior program, testprog.cpp that has a
couple of functions we can put breakpoints on.
It has a driver program, multi-process-driver.cpp, which links
against the LLDB solib and uses the SB APIs. It creates 50 pthreads,
creates a debugger on all of them, launches a debug session of the
inferior testprog, hits a couple breakpoints, walks the stack,
continues, etc., and then kills the inferior and ends the debug
session.
A pass is if all fifty debug sessions complete successfully
in the alloted time (~60 seconds).
We may need to tweak this one to work correctly on different
platforms/targets but I wanted to get it checked in to start.
llvm-svn: 212671
Marked skipped for Linux:
TestCallStopAndContinue
TestConvenienceVariables
TestStopHookMultipleThreads
Fixed up gdb-remote port-grabbing code to use a random port in a wide range,
and to allow that to fail more gracefully. This appears to have solved some
gdb-remote intermittent failing behavior.
llvm-svn: 212662
All tests matching '-p TestObjCMethods' now are marked correctly for MacOSX, and some
error classes have been removed in cleanup code looking for files that
might not exist due to previous failure.
See http://llvm.org/bugs/show_bug.cgi?id=20267
llvm-svn: 212650
The current strategy for host allocation is to choose a random
address and attempt to allocate there, eventually failing if the
allocation cannot be satisfied.
The C standard only guarantees that RAND_MAX >= 32767, so for
platforms that use a very small RAND_MAX allocations will fail
with very high probability. On such platforms (Windows is one),
you can reproduce this trivially by running lldb, typing "expr (3)"
and then hitting enter you see a failure. Failures generally
happen with a frequency of about 1 failure every 5 evaluations.
There is no good reason that allocations need to look like "real"
pointers, so this patch changes the allocation scheme to simply
jump straight to the end and grab a free chunk of memory.
Reviewed By: Sean Callanan
Differential Revision: http://reviews.llvm.org/D4300
llvm-svn: 212630
The getopt library has a structure called option (lowercase). We
have a structure called Option (uppercase). previously the two
structures had exactly the same definitions, and we were doing a
C-style cast of an Option* to an option*. C-style casts don't
bother to warn you when you cast to unrelated types, but in the
original OptionValidator patch I modified the definition of Option.
This patch fixes the errors by building an array of option
structures and filling it out the correct way before passing it to
the getopt library.
This also fixes one other source of test failures: an uninitialized
read that occurs due to not initializing a field of the
OptionDefinition.
Reviewed By: Todd Fiala
Differential Revision: http://reviews.llvm.org/D4425
llvm-svn: 212628
On MacOSX, we need to adjust the way we clean up the crashlog dylib in deleteCrashInfoDylib().
Right now it is only geared to run one test at a time. For now I'm just skipping the delete.
I'll work with Apple on a fix that handles this. It seems to only cause one dylib total to
hang around that might otherwise have been deleted. Fixes MacOSX multiple tests running
at the same time. (I didn't hit this on Yosemite, might be an issue that only shows up
on Mavericks?)
llvm-svn: 212548
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
This change modifies the way the multi-threaded test runner works.
It uses the Python multiprocessing library rather than the threading
library. Investigation showed that all MacOSX threads were waiting on
the global python lock when using the threading approach. Not sure
why that differed from the Linux/FreeBSD implementations.
The new approach uses the multiprocessing library's Pool class. It's
mildly cleaner than the other version, runs multithreaded on MacOSX,
and seems to have caused no performance regression on Linux. The
worker thread logic is simpler with the Pool managing the worker
processes.
This also includes a minor change to the test runner's python
lldb dir logic using the -P option. It now looks at the last line
of output rather than the first line. This covers part of the issue
of extra options validation logic getting spit out. The test runner
will now pick up the right python library directory. It does not
fix all the issues, though, as a ton of tests (50+ on Linux) are
failing due to unexpected output when running lldb.
llvm-svn: 212513
This patch implements basic functionality of the "platform process
list" command for Windows. Currently this has the following
limitations.
* Certain types of filtering are not enabled (e.g. filtering by
architecture with -a), although most filters work.
* The username of the process is not yet obtained.
* Using -v to list verbose information generates an error.
* The architecture column displays the entire triple, leading to
misaligned formatting of the printed table.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D4413
llvm-svn: 212510
Windows uses a different process security model and does not have
a concept of process UID or GID. This patch makes these options
invalid on Windows. Attempting to specify these options when the
current platform is Windows will generate an error.
Reviewed by: Jim Ingham
Differential Revision: http://reviews.llvm.org/D4373
llvm-svn: 212500
Teach add_lldb_library to correctly use the CMake 2.8.12
PUBLIC/PRIVATE/INTERFACE keywords. LLDB's CMake configuration would
inconsistently apply these keywords; this was previously a warning in
CMake 2.x but became an error in CMake 3.
llvm-svn: 212482
This change removes the ScriptInterpreter::TerminateInterpreter() call which
ended up endlessly calling itself as things currently stand. It also cleans
up some other Windows-related cmake changes.
See http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140630/011544.html
for more details.
Change by Zachary Turner
llvm-svn: 212320
Currently Windows disables Python builds by default. This
change ensures we don't process the scripts dir when we're
on Windows unless we're explicitly enabling python, which
prevents a build error.
Change by Deepak Panickal
llvm-svn: 212319
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
See http://reviews.llvm.org/D4366 for details.
Change by Paul Paul Osmialowski
Today this is the only problem that I'm facing trying to cross-compile lldb for AArch64 using Linaro's toolchain.
PTRACE_GETREGS, PTRACE_SETREGS, PTRACE_GETFPREGS, PTRACE_SETFPREGS are not defined for AArch64
These things can be defined different ways for other architectures, e.g. for x86_64 Linux, asm/ptrace-abi.h defines them as preprocessor constants while sys/ptrace.h defines them in enum along with corresponding PT_* preprocessor constants
NativeProcessLinux.cpp includes sys/ptrace.h
To avoid accidental redefinition of enums with preprocessor constants, I'm proposing this patch which first checks for PT_* preprocessor constants then checks for PTRACE_* constants then when it still can not find them, it defines preprocessor constants.
Similar approach was already used for PTRACE_GETREGSET and PTRACE_SETREGSET constants; in this case however it was easier, since enum values in sys/ptrace.h and preprocessor constants shared all exactly the same names (e.g. there's no additional PT_GETREGSET name defined).
llvm-svn: 212225
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
The only part using Carbon is a function in Host.mm used to open a file in Xcode.
That code is broken and it is no longer useful as Xcode supports LLDB natively.
llvm-svn: 212208
off_t is a type which is used for file offsets. Even more
specifically, it is only used by a limited number of C APIs that
deal with files. Any usage of off_t where the variable is not
intended to be used with one of these APIs is a bug, by definition.
This patch corrects some easy mis-uses of off_t, generally by
converting them to lldb::offset_t, but sometimes by using other
types such as size_t, when appropriate.
The use of off_t to represent these offsets has worked fine in
practice on linux-y platforms, since we used _FILE_OFFSET_64 to
guarantee that off_t was a uint64. On Windows, however,
_FILE_OFFSET_64 is unrecognized, and off_t will always be 32-bit.
So the usage of off_t on Windows actually leads to legitimate bugs.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D4358
llvm-svn: 212192
- Ported the SWIG wrapper shell scripts to Python so that they would work on Windows too along with other platforms
- Updated CMake handling to fix SWIG errors and manage sym-linking on Windows to liblldb.dll
- More build fixes for Windows
The pending issues are that two Python modules, termios and pexpect are not available on Windows.
These are currently required for the Python command interpreter to be used from within LLDB.
llvm-svn: 212111
There were a few places where we were not catching the possibility of negative
error codes in waitpid() calls. This change fixes those remaining after
the llgs branch fixes to ProcessMonitor.
Change by Shawn Best.
llvm-svn: 212107
With _HAS_EXCEPTIONS=0, Windows' version of <thread> will fail to
compile because it calls __uncaught_exception(), which is compiled
out due to _HAS_EXCEPTIONS=0. This just creates a stub version
of __uncaught_exception() which always fails.
llvm-svn: 212076
Also moves NativeRegisterContextLinux* files into the Linux directory.
These, like NativeProcessLinux, should only be built on Linux or a cross
compiler with proper headers.
llvm-svn: 212074
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
Both NativeProcessLinux (in llgs branch) and Linux Host.cpp had similar code to handle /proc
file reading. I factored that out into a new Linux-specific ProcFileReader class and added a method
that the llgs branch will use for line-by-line parsing.
This change also adds numerous Linux-specific files to Xcode that were missing from the Xcode
project files.
Related to https://github.com/tfiala/lldb/issues/27
llvm-svn: 212015
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
Also added tests for presence of vCont;c, vCont;C, vCont;s, vCont;S as
returned by vCont? query.
Broke out single step functionality from TestLldbGdbServer into base class.
Used by new TestGdbRemoteSingleStep (using $s) and TestGdbRemote_vCont.
Also part of llgs wrap-up, see:
https://github.com/tfiala/lldb/issues/12
llvm-svn: 211965
Removed the distribution EXEs from FreeBSD and Ubuntu.
Added a hello-world .cpp file, and compiled it for
several platform/compiler variants:
Ubuntu 14.04 x86_64, clang 3.5 (the ubuntu1 3.5 pre variant)
Ubuntu 14.04 x86_64, gcc 4.8.2
FreeBSD 10.0 x86_64, clang 3.3
FreeBSD 10.0 x86_64, gcc 4.7.3
NetBSD 6.1 x86_64, gcc 4.5.3
I also added the NetBSD expected architecture and triple.
Note I have NetBSD not appending the version info to the
OS name, in contrast to FreeBSD.
llvm-svn: 211954
Previously ObjectFileELF was simplifying and assuming the object file it was
looking at was the same as the host architecture/triple. This would break
attempts to run, say, lldb on MacOSX against lldb-gdbserver on Linux since
the MacOSX lldb would say that the linux elf file was really an Apple MacOSX
architecture. Chaos would ensue.
This change allows the elf file to parse ELF notes for Linux, FreeBSD and
NetBSD, and determine the OS appropriately from them. It also initializes
the OS type from the ELF header OSABI if it is set (which it is for FreeBSD
but not for Linux).
Added a test with freebsd and linux images that verify that
'(lldb) image list -t -A' prints out the expected architecture for each.
llvm-svn: 211907
python bindings.
For example, this prevents errors on systems that disable python because
the system python isn't available. Without this, we still try to install
things and get install errors when that doesn't work.
llvm-svn: 211899
Replace adhoc inline implementation of llvm::array_lengthof in favour of the
implementation in LLVM. This is simply a cleanup change, no functional change
intended.
llvm-svn: 211868
Now that I'm building Linux with clang, I'm seeing more clang warnings.
This fills in some extra fields missing in the final end-of-structure-array
marker.
llvm-svn: 211812
Previously, only the starting locations of the candidate interval
and the existing interval were compared. To correctly detect
range intersections, it is necessary to compare the entire range
of both intervals against each other.
Reviewed by: scallanan
Differential Revision: http://reviews.llvm.org/D4286
llvm-svn: 211726
Not all supported compilers have GCC intrinsics, so this patch
uses the correct portable alternative.
Additionally, this patch fixes an off-by-one error. __builtin_ffs
returns the 1-based index of the least-significant 1-bit, but the
function expects the base 2 logarithm of the number, which is
equivalent to the 0-based index of the least-significant 1-bit.
Reviewed by: Keno Fischer
Differential Revision: http://reviews.llvm.org/D4284
llvm-svn: 211669
Clean up this one specifically, as it has the effect of double-spacing
the list of thread stop reasons, and substantially bloats the log file
when opening a core with hundreds of threads.
There are other cases of extra newlines. Some of them do increase
readability, so avoid a general sweep for now.
llvm-svn: 211655
The patch is as is with the functionality left disabled for apple vendors because of performance regressions. If this is enabled it ends up searching for symbols in all shared libraries that are loadeded.
llvm-svn: 211638
process fully reaped. The race & bad behavior was because we were letting
the reaping thread in LLDB to also set the Process exit status, so debugserver
would sometimes be shut down before it got a chance to report the exit status,
and then we got confused.
<rdar://problem/16555850>
llvm-svn: 211636
r209631: Use MIUtilSystemLinux on FreeBSD as well
We should later rename this file (probably MIUtilSystemPOSIX), but
more clean-up is still needed here, and we can wait until we better
understand how this code may be shared between FreeBSD, Linux, and OS X.
r209632: Add stdlib.h for malloc and friends
r209633: Remove include of obsolete stropts.h header
The header is for POSIX streams functionality, and does not exist on
FreeBSD, OS X, or contemporary Linux distributions.
Issue reported by John Wolfe.
llvm-svn: 211620
mistake in the lock acquistion in HistoryUnwind and HistoryThread.
We've got a deadlock with one use case of HistoryUnwind; I
need to figure out what lock ordering is causing this and fix
it for real.
<rdar://problem/17411904>
llvm-svn: 211541
I missed adding a few new files to the change list.
The build is broken from r211526 without this fix.
(And Ed Maste caught it before I did, so this is
the remainder - the test methods).
llvm-svn: 211535
See http://reviews.llvm.org/D4221 for details.
This commit allows you to control the signals that lldb will suppress, stop or forward using the Python and C++ APIs.
Change by Russell Harmon.
Xcode build system changes (and any mistakes) by Todd Fiala. Tested on MacOSX 10.9.3 and Xcode 6 beta. (Xcode 5 is hitting the dependency checker crasher on all my systems).
llvm-svn: 211526
When a stub reported $#00 (unsupported) for _M and _m
packets, the unsupported response was not handled and
the client then marked the _M/_m commands as definitely
supported. However, they would always fail, preventing
lldb's fallback InferiorCallMmap-based allocation strategy
from being used to attempt to allocate memory in the inferior
process space.
llvm-svn: 211425
Tests for both thread suffix and no thread suffix execution.
Moved some bit-flipping helper methods from TestLldbGdbServer
into the base GdbRemoteTestCaseBase class.
llvm-svn: 211381
The issue was when we called Debugger::RunIOHandler(), it would run the current IOHandler by activating it, and running it and then try to pop it and exit regardless of wether it was on top or not.
The new code will push the IOHandler that was passed in, and run the IOHandlers until the one passed in is successfully popped. This allows files for the "command source" to switch input handlers:
% cat /tmp/commands
br s -S alignLeftEdges:
br command add
bt
frame var
po self
DONE
b s -n main
br command add
bt
frame var
DONE
Note above we set a breakpoint, then add commands do it. The "br command add" will push the breakpoint comment gatherer until it sees "DONE" and then pop itself off the stack. The a new breakpoint will be set and it does the same thing again.
Now this file can be sourced from the command line:
% lldb -s /tmp/commands /path/to/a.out
And your breakpoints will be correctly setup!
<rdar://problem/17081650>
llvm-svn: 211329
directly accessing the isa pointer of a class object to get its meta-class, but the isa
pointers are not simple pointers on arm64, so this would cause the stepping to fail.
object_getClass does whatever magic needs doing in this case.
<rdar://problem/17239690>
llvm-svn: 211289
Fixes two causes for https://github.com/tfiala/lldb/issues/7.
1. Ensures the inferior program has started executing, by printing
a message on output first thing (per the "message:" command line arg)
and waiting for that text to arrive before doing any checks related
to auxv support.
2. Fixes up auxv-related regex patterns to be compiled with the Python
re.MULTILINE and re.DOTALL options. The multiline is needed because
the binary data can include what look like newlines when interpreted
as text, and the DOTALL is needed to have the (.*) content portion match
newlines.
Added interrupt packet helper methods to add interrupt test sequence
packets and parse the results from them.
llvm-svn: 211283
to modify the same UnwindTable object simultaneously. Fix
HistoryThread and HistoryUnwind's mutex lock acqusition to
retain the lock for the duration of the operation instead of
releasing the temporary immediately.
<rdar://problem/17055023>
llvm-svn: 211241
The compiler, when JIT'ing code, can emit illegal DWARF line tables (address is line table sequences must increase). This changes fixes that issue by replacing previous line entries whose start address is the same with the new line entry to avoid having multiple line entries with the same address. Since the address range of lines entries is determined by the delta between the current and next line entry, this shouldn't cause any issues.
llvm-svn: 211212
Change r210035 broke the Darwin cmake build. The
initial change was intended to stop the --start-group/--end-group
linker flags from being passed to non-gcc/clang-looking compilers,
stopping MSVC from warning on linking. That change, however,
caused MacOSX cmake-based builds to start using the --start-group/
--end-group flags, even though the MacOSX linker doesn't support
them. That broke the MacOSX clang build.
The fix keeps the newer check for a gcc-compatible compiler, but
specifically excludes MacOSX.
llvm-svn: 211123
First batch of auxv-related tests from llgs branch.
Includes helpers for unescaping gdb-remote binary-escaped
data, converting binary data from inferior endian-ness to
integral values, etc.
Tests on debugserver are expected to be skipped since it
doesn't support auxv and the tests are geared to be skipped
on platforms that don't broadcast support for the feature
in qSupported. (llgs is listed as XFAIL since qSupported
support in llgs upstream is not there, so the support check
cannot work in upstream llgs.)
llvm-svn: 211105
Issue discovered during the GSoC 2014 project implementing FreeBSD
kernel support. The existing elf-core Process plugin crashed trying
to read from /dev/mem (the kernel memory device).
Patch by Mike Ma.
llvm-svn: 211102
Building OS X debugserver assumes you have an Xcode installation at /Application/Xcode.app. Let's instead detect where Xcode is using xcrun.
See http://reviews.llvm.org/D4152
llvm-svn: 211074
command instead of a script.
In addition to cleaning things up, this allows more easy access to the
variables. In the old version, it tried to pass variables as -D flags to
cmake, but this didn't actually work. CMake drops all of those arguments
on the floor (try passing garbage through them) and just picks up the
limited subset of pre-defined macros. So, for example, this fixes the
build with LLVM_LIBDIR_SUFFIX=64 which is how I ended up here. =]
llvm-svn: 211028
RegisterSets are assumed to be terminated by this value. Loops over
register set values would fail without LLDB_INVALID_REGNUM terminating
the list. This change adjusts the static check to account for the
size of the register set regnum list being one larger than the expected
valid register set count.
llvm-svn: 210964
The llgs branch had a bug where register sets were not terminated with
LLDB_INVALID_REGNUM so the expedite register loop was issuing duplicate
registers. This test was added to catch the problem.
Enhanced the key-val collection method to optionally (and by default)
support capturing duplicate values for a given key. When that happens
and if permitted, it promotes a single key to a list and appends values
to it.
llvm-svn: 210963
I've been making some subtle changes to the gdb-remote tests as I implement
them in the llgs branch. This check-in rectifies the set of diffs that
have accumulated in the llgs branch that were not present upstream.
llvm-svn: 210957
Expedited registers currently checked for are pc, fp and sp.
Also broke out the gdb-remote base test case logic into
class gdbremote_testcase.GdbRemoteTestCaseBase in the new
gdbremote_testcase.py file.
TestGdbRemoteExpeditedRegisters.py is the first gdb-remote area
to be contained in its own test case class file.
The monolithic TestLldbGdbServer.py has been modified to derive
from gdbremote_testcase.GdbRemoteTestCaseBase. Soon I will
pull out all the gdb-remote functional area tests from that class
into separate classes.
I'm intending to start all GdbRemote test cases with GdbRemote
so it is easy to run them all with a -p pattern match on the
test run infrastructure.
Also scanned and removed all cases of whitespace-only lines in
the files I touched.
llvm-svn: 210931
Address the 'variable set but not used' warning from GCC. In some cases a few
additional calls were removed where there should be no visible side effects of
the calls (i.e. should not effect any cached state).
llvm-svn: 210879
lldb support. I'll be doing more testing & cleanup but I wanted to
get the initial checkin done.
This adds a new SBExpressionOptions::SetLanguage API for selecting a
language of an expression.
I added adds a new SBThread::GetInfoItemByPathString for retriving
information about a thread from that thread's StructuredData.
I added a new StructuredData class for representing
key-value/array/dictionary information (e.g. JSON formatted data).
Helper functions to read JSON and create a StructuredData object,
and to print a StructuredData object in JSON format are included.
A few Cocoa / Cocoa Touch data formatters were updated by Enrico
to track changes in iOS 8 / Yosemite.
Before we query a thread's extended information, the system runtime may
provide hints to the remote debug stub that it will use to retrieve values
out of runtime structures. I added a new SystemRuntime method
AddThreadExtendedInfoPacketHints which allows the SystemRuntime to add
key-value type data to the initial request that we send to the remote stub.
The thread-format formatter string can now retrieve values out of a thread's
extended info structured data. The default thread-format string picks up
two of these - thread.info.activity.name and thread.info.trace_messages.
I added a new "jThreadExtendedInfo" packet in debugserver; I will
add documentation to the lldb-gdb-remote.txt doc soon. It accepts
JSON formatted arguments (most importantly, "thread":threadnum) and
it returns a variety of information regarding the thread to lldb
in JSON format. This JSON return is scanned into a StructuredData
object that is associated with the thread; UI layers can query the
thread's StructuredData to see if key-values are present, and if
so, show them to the user. These key-values are likely to be
specific to different targets with some commonality among many
targets. For instance, many targets will be able to advertise the
pthread_t value for a thread.
I added an initial rough cut of "thread info" command which will print
the information about a thread from the jThreadExtendedInfo result.
I need to do more work to make this format reasonably.
Han Ming added calls into the pmenergy and pmsample libraries if
debugserver is run on Mac OS X Yosemite to get information about the
inferior's power use.
I added support to debugserver for gathering the Genealogy information
about threads, if it exists, and returning it in the jThreadExtendedInfo
JSON result.
llvm-svn: 210874
(lldb) file /bin/ls
(lldb) b malloc
(lldb) run
(lldb) process save-core /tmp/ls.core
Each ObjectFile plug-in now has the option to save core files by registering a new static callback.
llvm-svn: 210864
Improved the P writes all GPR register values test. It now
limits itself to GPR registers that are not containers for
other registers. Pulled in improvements from the llgs branch.
Note on Linux llgs I'm able to write a much wider range
of registers successfully with $P using the bitflip test than I am able
to write with debugserver. Might be worth drilling into.
llvm-svn: 210818
Added test that attempts to write a value to each general
purpose register that is bit-flipped from the initial read
value. It then reads it back to see if it takes.
Right now I just assert that at least one register bit flip
write succeeds. I added a note that on the MacOSX x86_64
debugserver case, the only writes that succeed from the GPR
set are rax thru rdx, rdi, rsi and rbp. The failures are E32
failure-at-write-attempt issues on the debugserver end.
I'll revisit this after implementing in the llgs linux-x86_64 branch.
The packet log looks good but I may have a subtle mistake in the code.
llvm-svn: 210681
Initial check-in provided a nibble count instead of byte count for
the memory to write. Fixed that.
Enhanced test to check for overwrite past the expected range of
writing to verify the correct amount is written.
llvm-svn: 210602
We preivously had two copies of ::BytesAvailable with only trivial
differences between them, and fixes have been applied to only one of
them.
Instead of duplicating the whole function, hide the FD_SET differences
behind a macro. This leaves only one small __APPLE__-specific #if
block, and fixes ^C on non-__APPLE__ platforms.
llvm-svn: 210592
Modified the breakpoint stop and start check to verify the program
counter printed immediately after stopping does match the breakpoint
address. This is based on a conversation with Greg Clayton clarifying
that the breakpoint stop handling code on a remote should do any and
all adjusting of the program counter at stop time, not at resume time.
Added a qProcessInfo parser and helper methods to add the collection
send/response elements to the packet flow. Removed the older pid-only
query mechanism. The parser verifies all the keys provided are within
the documented known set of key-value pairs.
Added helper routine to unpack the hex value of a $p-style register
read response according to the endian-ness of the inferior as reported
by qProcessInfo.
Added a test to verify qProcessInfo includes an endian key/value pair.
Refactored several older tests to move to the less verbose test
startup code. Most of these were the tests using the older
qProcessInfo pid-only retrieval code.
llvm-svn: 210374
Tests $Z0 and $z0. Extends test exe get-code-address-hex:
to take a function name.
Enabled for debugserver, disabled for llgs. Implementing
in llgs branch next.
llvm-svn: 210272
lldb-gdbserver and NativeProcessProtocol will use MemoryRegionInfo
but don't want to pull in Process.h. Pull this declaration and
definition out into its own header.
llvm-svn: 210213
Added two new tests: one to verify that a test exe heap address
returned is readable and writeable, and a similar one to verify
a test exe stack address is readable and writeable.
Ran the main.cpp test exe code through the Xcode re-indenter.
I was using TextMate to edit the test's C++ code alongside the
Python code but last check-in found that it was not handling
tabs/indentation the way I am intending it.
Modified test exe to require C++11.
Refactored gdb remote python code's handling of memory region
info into more re-usable methods.
llvm-svn: 210196
Added test stub for collecting a code, heap and stack address.
Added test to verify that the code address returns a readable,
executable memory region and that the memory region range
was indeed the one that the code belonged to.
llvm-svn: 210187
Added set-memory:{content} and get-memory-address-hex: commands
to the test exe for gdb-remote. Added a test that sets the content
via the inferior command line, then reads it back via gdb-remote
with $m.
Passing on debugserver. Marked as fail on llgs. Implementing
in the llgs branch next.
llvm-svn: 210116
- Fix Xcode project to have source files for SBTypeEnumMember.h/SBTypeEnumMember.cpp in the right place
- Rename a member variable to inluce "_sp" suffix since it is a shared pointer
- Cleanup initialization code for TypeEnumMemberImpl to not warn about out of order initialization
llvm-svn: 210051
I switched the lldb_private::FileSpec code over to use "llvm::StringRef llvm::sys::path::filename(llvm::StringRef)" for basename() and "llvm::StringRef llvm::sys::path::parent_path(llvm::StringRef)" for dirname().
<rdar://problem/16870083>
llvm-svn: 209917
Learned that MacOSX only accepts signal delivery on a thread that is
already signal handling. Reworked the test exe to cause a SIGSEGV
and recover if either nothing intercepts the SIGSEGV handler, or
if a SIGUSR1 is inserted. The test uses the latter part to test
signal delivery on continue using the SIGUSR1.
I still don't have this working on MacOSX. I'm seeing the
signal get delivered to a different thread than the one I'm
specifying with $Hc{thread-id} + $C{signo}, or with
$vCont;C{signo}:{thread-id};c. I'll come back to this
after getting it working on the llgs branch on Linux x86_64.
llvm-svn: 209912
Changes include:
- ObjectFileMachO can now determine if a binary is "*-apple-ios" or "*-apple-macosx" by checking the min OS and SDK load commands
- ArchSpec now says "<arch>-apple-macosx" is equivalent to "<arch>-apple-ios" since the simulator mixes and matches binaries (some from the system and most from the iOS SDK).
- Getting process inforamtion on MacOSX now correctly classifies iOS simulator processes so they have "*-apple-ios" architectures in the ProcessInstanceInfo
- PlatformiOSSimulator can now list iOS simulator processes correctly instead of showing nothing by using:
(lldb) platform select ios-simulator
(lldb) platform process list
- debugserver can now properly return "*-apple-ios" for the triple in the process info packets for iOS simulator executables
- GDBRemoteCommunicationClient now correctly passes along the triples it gets for process info by setting the OS in the llvm::Triple correctly
<rdar://problem/17060217>
llvm-svn: 209852
Added new SocketPacketPump class to decouple gdb remote packet
reading from packet expectations code. This allowed for cleaner
implementation of the separate $O output streams (non-deterministic
packaging of inferior stdout/stderr) from all the rest of the packets.
Added a packet expectation matcher that can match expected accumulated
output with a timeout. Use a dictionary with "type":"output_match".
See lldbgdbserverutils.MatchRemoteOutputEntry for details.
Added a gdb remote test to verify that $Hc (continue thread selection)
plus signal delivery ($C{signo}) works. Having trouble getting this
to pass with debugserver on MacOSX 10.9. Tried different variants,
including $vCont;C{signo}:{thread-id};c. In some cases, I get the
test exe's signal handler to run ($vCont variant first time), in others I don't
($vCont second and further times). $C{signo} doesn't hit the signal
handler code at all in the test exe but delivers a stop. Further
$Hc and $C{signo} deliver the stop marking the wrong thread. For now I'm
marking the test as XFAIL on dsym/debugserver. Will revisit this on
lldb-dev.
Updated the text exe for these tests to support thread:print-ids (each
thread announces its thread id) and provide a SIGUSR1 thread handler
that prints out the thread id on which it was signaled.
llvm-svn: 209845
Disables exception handling in LLDB, using appropriate compiler
flags depending on the platform. This is consistent with the build
of LLVM, should improve performance, and also removes a substantial number
of warnings from the Windows build.
See http://reviews.llvm.org/D3929 for more details.
Change by Zachary Turner
llvm-svn: 209752
This fixes a number of trivial warnings in the Windows build. This is part of a larger effort to make the Windows build warning-free.
See http://reviews.llvm.org/D3914 for more details.
Change by Zachary Turner
llvm-svn: 209749
We should later rename this file (probably MIUtilSystemPOSIX), but
more clean-up is still needed here, and we can wait until we better
understand how this code may be shared between FreeBSD, Linux, and OS X.
llvm-svn: 209631
Removed a "done" TODO comment.
Moved some helper methods to the top of the unit test.
Removed some commented out code I was considering implementing
before I came up with a better overall approach.
llvm-svn: 209561
Added test to check that each thread reported by $q{f,s}ThreadInfo
can be switched to by $Hg, verified by a follow-up $qC.
Modified test exe to accept "thread:new" to create a new thread
that runs and sleeps for 5 seconds.
@llgs_test/@debugserver_test now buffer output.
llgs and debugserver gdbremote protocol tests now collect $O notification
output into the context returned from expect_lldb_gdbserver_replay.
context["O_count"] is an integer indicating the number of $O packets
collected during the replay, and context["O_content"] contains the
accumulated hex-decoded text output by the inferior (stdout and stderr).
Modified the $O check test to check the accumulated output rather than
a direct $O packet.
llvm-svn: 209560
of the symbol itself rather than forcing clients to do
it. This simplifies the logic for the expression
parser a great deal.
<rdar://problem/16935324>
llvm-svn: 209494
and sharing it with all of its FuncUnwinders, have each FuncUnwinder
create an AssemblyProfiler on demand as needed. I was worried that
the cost of creating the llvm disassemblers would be high for this
approach but it's not supposed to be an expensive operation, and it
means we don't need to add locks around this section of code.
<rdar://problem/16992332>
llvm-svn: 209493
to its unwind assembly profiler to all of the FuncUnwinders (one
per symbol) under it. If lldb is running multiple targets, you
could get two different FuncUnwinders in the same Module trying
to use the same llvm disassembler simultaneously and that may be
a re-entrancy problem.
Instead, the UnwindTable has the unwind assembly profiler and when
the FuncUnwinders want to use it, they get exclusive access to
the assembly profiler until they're done using it.
<rdar://problem/16992332>
llvm-svn: 209488
Each register returned by $qRegisterInfo is tested that it's
$p register read returns a representation that is the correct byte size
as indicated by $qRegisterInfo.
Currently enabled for debugserver, disabled for llgs.
The llgs branch will use this to verify $p implementation.
llvm-svn: 209452
read requests into smaller chunks; some remote kdp stubs
cannot handle memory reads larger than a KB or two & will
error out.
<rdar://problem/16983125>
llvm-svn: 209341
Added helper methods:
prep_debug_monitor_and_inferior(): properly handles
the two cases of running the stub against an inferior process
launched by the stub, and one attached to by the stub. See
docs for function: simplifies test creation for tests that want
to test the same operations against a launched and attached inferior.
Added the q{f,s}ThreadInfo and $qC response comparison test (verifies
they both return the same thing) when the process is attached rather
than launched by the stub.
Modified the previous two tests added to make use of the new
prep_debug_monitor_and_inferior() facility.
llvm-svn: 209318
The First test verifies that qThreadInfo queries work for stub-launched processes.
The second test verifies that $qC after stub-launched inferior returns the same
thread as the qThreadInfo queries.
llvm-svn: 209314
The multi request-response test infrastructure support was adding
the optional request suffix iteration index as decimal but it needed
to be hex per spec. This change fixes that.
llvm-svn: 209234
Added support for gdb remote protocol capture/playback where there is a query/multiple-response
pattern. The new playback entry supports:
- a general query command (key: next_query or query)
- an optional first-query command if that differs from the subsequent queries (key: first_query)
- an end regex for matching anything that would signify that the query/multi-response
iteration has come to an end. An assumption is that the end regex is not a content
package we care about aside from ending the iteration. (key: end_regex)
- an optional 0-based index appended to the end of the query command
(key: append_iteration_suffix), default: False.
- a key used to collect responses from the query. Any response from the gdb remote
that doesn't match the end-of-iteration regex is captured in the playback context
dictionary using the key specified. That key will be an array, where each array
entry is one of the responses from the query/multi-response iteration. (key: save_key).
- a runaway response value, defaulting to 10k, where if this many responses is captured,
assume the ending condition regex is invalid, or the debug monitor is doing something
goofy that is going to blow out memory or time. (key: runaway_response_count, default: 10000)
See the lldbgdbserverutils.MultiResponseGdbRemoteEntry class for details.
A MultiResponseGdbRemoteEntry is added by adding an element to the GdbRemoteTestSequence
(via GdbRemoteTestSequence.add_log_lines), using a dictionary, where the "type" key
is set to "multi_response", and the rest of the keys in the dictionary entry are
set to the keys documented for MultiResponseGdbRemoteEntry.
Added helper functions to add the required entry to grab all qRegisterInfo responses.
Added another helper to parse the qRegisterInfo response packets into an array of
dictionaries, where each key:value in the dictionary comes from the register info
response packet.
Added a test to verify that a generic register exists for the program counter,
frame pointer, stack pointer and cpu flags across all register info responses.
Added a test to verify that at least one register set exists across all register
info responses.
llvm-svn: 209170
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
Checks that at at least qRegisterInfo0 responds with a valid
register info reply packet. The packet is parsed and validates
that all keys come from the documented set of valid keys. It
then validates that a minimum set of expected keys
are present in the returned packet.
This test is set to pass on debugserver and fail on llgs TOT.
llvm-svn: 209109
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
Rationale:
Pretty simply, the idea is that sometimes type names are way too long and contain way too many details for the average developer to care about. For instance, a plain ol' vector of int might be shown as
std::__1::vector<int, std::__1::allocator<....
rather than the much simpler std::vector<int> form, which is what most developers would actually type in their code
Proposed solution:
Introduce a notion of "display name" and a corresponding API GetDisplayTypeName() to return such a crafted for visual representation type name
Obviously, the display name and the fully qualified (or "true") name are not necessarily the same - that's the whole point
LLDB could choose to pick the "display name" as its one true notion of a type name, and if somebody really needs the fully qualified version of it, let them deal with the problem
Or, LLDB could rename what it currently calls the "type name" to be the "display name", and add new APIs for the fully qualified name, making the display name the default choice
The choice that I am making here is that the type name will keep meaning the same, and people who want a type name suited for display will explicitly ask for one
It is the less risky/disruptive choice - and it should eventually make it fairly obvious when someone is asking for the wrong type
Caveats:
- for now, GetDisplayTypeName() == GetTypeName(), there is no logic to produce customized display type names yet.
- while the fully-qualified type name is still the main key to the kingdom of data formatters, if we start showing custom names to people, those should match formatters
llvm-svn: 209072
Also moved it into the lldb_private namespace.
The llgs branch is making use of this interface and its use is not
strictly limited to POSIX.
llvm-svn: 209016
Use a map rather than a vector to store the objects managed by the shared
cluster since mostly want this for random lookup, so the map is much faster.
llvm-svn: 209010
- 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
Checks that the pid reported by $qProcessInfo matches the pid that was
launched as the attach test subject.
test exe now supports "sleep:{sleep_seconds}" command line argument.
llvm-svn: 208782
See thread here:
http://lists.cs.uiuc.edu/pipermail/lldb-dev/2014-May/003992.html
This is meant to address case 3 that I recently broke with an earlier
change to rectify usage of the $qC message for thread ids, specifically:
3. TOT lldb <=> gdbserver (without $qProcessInfo support and not Apple/iOS).
llvm-svn: 208741
the SystemRuntime to check if a thread will have any problems
performing an inferior function call so the driver can skip
making that function call on that thread. Often the function
call can be executed on another thread instead.
<rdar://problem/16777874>
llvm-svn: 208732
The clean line is failing under Ubuntu 12.04/gcc. It cleans fine
without it on MacOSX. It doesn't clean right on Linux but at least
now it doesn't fail the test.
llvm-svn: 208713
Python defines _XOPEN_SOURCE and _POSIX_C_SOURCE unconditionally. On Linux,
this is problematic as glibc's features.h defines these values if _GNU_SOURCE is
defined to the value that is currently implemented. Python defines it to the
versions that it requires, which may be different. Undefine the macros on Linux
(technically, this should be safe to do globally) before including the python
headers.
llvm-svn: 208520
another way to indicate that this register is a generic
Return Address register (in addition to "ra") - this is
used primarily by OperatingSystem plugins.
Correctly annotate the UnwindPlan created by EmulateInstructionARM64
to indicate that it was not sourced from a compiler and it
is valid at every instruction.
<rdar://problem/16639754>
llvm-svn: 208390
$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
The FreeBSD package building cluster installs e.g. 'python2.7', but no
plain 'python' to avoid version-related issues.
CMake's FindPythonInterp locates an interpreter with such a name and
provides it in the PYTHON_EXECUTABLE variable. Use that if it's set,
falling back to the original '/usr/bin/env python' otherwise.
This is a missing part of LLDB commit r207122.
Patch by Brooks Davis in FreeBSD ports commit r353052
llvm-svn: 208204
Added a test validating that $qC after an inferior launch via $A
returns a thread id that an immediately followig $? reports for the
active thread. This is currently skipped on debugserver (the thread
ids don't match) and isn't yet implemented in TOT for llgs.
llvm-svn: 208061
data if it is available.
Change ProcessGDBRemote's maximum read/write packet size from a
fixed 512 byte value to asking the remote gdb stub what its maximum
is, using up to 128kbyte sizes if that's allowed, and falling back
to 512 if the remote gdb stub doesn't advertise a max packet size.
Add a new "process plugin packet xfer-size" command that can be used
to override the maximum packet size (although not exceeding any packet
size maximum published by the remote gdb stub).
<rdar://problem/16032150>
llvm-svn: 208058
Pushed gdbremote protocol sequence expectations into a separate
class and defer matching of llgs/debugserver output to the
sequence entry. Pre-step to adding regex matching and
grouped content collecting.
No longer require anything before the read/send packet
portion of slurped-up log lines used for setting up
gdb remote test sequences. Several packet logging options
produce a wide range of content before the read/send packet.
Added helpers to TestLldbGdbServer to clean up test setup
and test expectations matching.
llvm-svn: 207998
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
Tests added for debugserver and lldb-gdbserver. lldb-gdbserver marked as
XFAIL on top of tree.
Added build_gdbremote_A_packet test helper to construct a gdbremote A
launch packet from a list of args.
llvm-svn: 207568
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
- Remove default for switch which covers all enumeration values
- Remove unused functions
LSL_C is left in the source under #if 0, as it may be needed in the
future for emulating other instructions.
Differential Revision: http://reviews.llvm.org/D3528
llvm-svn: 207449
TestLldbGdbServer now supports both lldb-gdbserver (llgs) and
debugserver tests. Similar to the dsym/dwarf tests, they allow
running the same underlying gdb remote protocol tests against
lldb-gdbserver and debugserver. This will help make sure the
protocol-level tests for lldb-gdbserver faithfully represent
what debugserver does on OS X.
Switched back gdb remote protocol test logging to warning
and above (accidentally submitted it at debug level in a
recent commit).
llvm-svn: 207395
Adds try/except blocks around clean-up code. Prevents a race between gdb
remote kill command reception by llgs (which leads llgs to shut down)
and the pexpect server kill (which can fail if the kill command handling
completes first). Warnings are emitted on the logger for any clean-up
code that fails.
llvm-svn: 207273
optional path prior to the file base name.
On Linux x86_64 (Ubuntu 12.04) I am sometimes getting a full path
on the stderr.txt. This changes the test for target.error-path and
target.output-path settings to ignore any optional directory before
the expected file base name.
llvm-svn: 207272
It looks like on 18th April clang added dependency from clangCodeGen.a to
LLVMProfileData.a and since then lldb have problem with linking to
clangCodeGen.a due to missing symbols.
This adds LLVMProfileData.a to USEDLIBS to fix that problem.
Patch by Robert Matusewicz.
llvm-svn: 207216
Currently if you run _any_ python, python has the "lldb.debugger" global variable and it has a strong reference to a lldb_private::Debugger since it is a lldb::SBDebugger object with a shared pointer.
This makes sure that your LLDB command interpreter history is saved each time you quit command line LLDB.
llvm-svn: 207164
currently associated with a given thread, on relevant targets.
Change the queue detection code to verify that the queues
associated with all live threads are included in the list.
<rdar://problem/16411314>
llvm-svn: 207160
values of variables in the Materializer.
The Materializer should not write the variable
back if its new value is the *same* as the old
value, not if the new value is *different*.
<rdar://problem/16712205>
llvm-svn: 207148
The FreeBSD package building cluster installs e.g. 'python2.7', but no
plain 'python' to avoid version-related issues.
CMake's FindPythonInterp locates an interpreter with such a name and
provides it in the PYTHON_EXECUTABLE variable. Use that if it's set,
falling back to the original '/usr/bin/env python' otherwise.
Patch by Brooks Davis in FreeBSD ports commit r352012
llvm-svn: 207122
This decision has always been statically-bound to the individual formatter. With this patch, the idea is that this decision could potentially be dynamic depending on the ValueObject itself
llvm-svn: 207046
lldbgdbserverutils.py has a new expect_lldb_gdbserver_replay() method
that plays back gdb remote send/receive packets. These packets are the
log lines that come from running the 'log enable gdb-remote packets',
either from the lldb-gdbserver side or the lldb side. There's a flag
to flip which side is the send (lldb-gdbserver input or lldb-gdbserver
output).
This first checkin tests the initial gdbremote handshake, the ability
to turn on the no-ack mode communication style, thread suffix support,
and list threads in stop reply support. The last two are marked xfail
as top of tree does not yet support these.
--This line, and those below, will be ignored--
M test/tools/lldb-gdbserver/TestLldbGdbServer.py
M test/tools/lldb-gdbserver/lldbgdbserverutils.py
llvm-svn: 206930
Since these tests pass on (at least some) other platforms, change the
decorators to @expectedFailureDwarwin. Tested on FreeBSD with Clang 3.4
and libc++.
rdar://9980907
rdar://15367233
llvm-svn: 206895
This updates the target_link_libraries invocation when building with CMake
2.8.12 or newer. The newer version of CMake warns when keyword and plain
signatures are used for target_link_libraries. This addresses that difference
while maintaining compatibility with the older releases by defining a macro for
the keyword that is defined based on the current version of CMake.
Patch originally by chapuni!
llvm-svn: 206850
Our build is still getting this test to fail with the presence of const in
'(Foo &const) y = 0x' and '(Foo &&const) z = 0x'. This change simply changes
the match substrings to ignore the portion after the final '&' and before the
closing ')'. This should cover the presence (or absence) of the const qualifier.
llvm-svn: 206762
The underlying issue was actually a Clang bug, now fixed. The test now
reports XPASS for me locally and on the buildbot.
llvm.org/pr17183 (LLDB)
llvm.org/pr18950 (Clang)
llvm-svn: 206761
Perhaps these should be @expectedFailureDarwin instead of
@unittest2.expectedFailure (applying to all hosts); I'm not aware of
the details in the rdars.
Just add a comment for now, for the benefit of anyone investigating
FreeBSD test issues in the future.
rdar://9980907
rdar://15367233
llvm-svn: 206760
The additional "const" breaks the FreeBSD buildbot, and does not appear
to be due to a LLVM or Clang change. Revert the change while
investigating further.
This reverts revision 206619.
llvm-svn: 206751
The lldb-gdbserver tests are skipped if the lldb-gdbserver exe cannot be found (currently only built for Linux and FreeBSD). The lldb-gdbserver exe is found by the LLDB_EXEC environment variable, using the same dir as the lldb exe, and then replacing lldb with lldb-gdbserver.
llvm-svn: 206731
When compiling on Linux with GCC 4.8, compilation would fail due to the use of
the offsetof macro. This is a standard macro, defined in stddef.h. Include
this header to ensure that offsetof is declared.
llvm-svn: 206702
when it is reading the kext table, in case we're reading out of a core file with
corrupt contents in this region.
<rdar://problem/16601915>
llvm-svn: 206233
The "unexpected value" message only matters to me, but is bound to make the experience more confusing for people when some uninitialized memory looks like an NSNumber and then can't be formatted properly, and that error comes out in the UI
Just drop the error message entirely - nobody but me cares
llvm-svn: 205978
Enable data formatters to see-through pointers/references to typedefs
For instance, if Foo is a typedef to Bar, and there is a formatter for any/all of Bar*, Bar&, Bar&&, then Foo*, Foo&, and Foo&& should pick these up if Foo-specific formatters don't exist
llvm-svn: 205939
Set the correct FormatManager revision before starting to figure out the new formatters
This can avoid entering some corner cases where as part of figuring out formatters we try to figure out dynamic types, and in turn that causes us to go back in trying to fetch new formatters - it is not only a futile exercise, it's also prone to endless recursion
This would only cause a behavior change if getting this chain started would eventually cause something to run and alter the formatters, a very unlikely if at all possible sequence of events
llvm-svn: 205928
TIDs are conventionally shown as decimal values on FreeBSD and Linux.
Thus, use the ${thread.id%tid} format string to display the thread ID,
instead of a fixed hex format.
llvm.org/pr19380
llvm-svn: 205912
Calling mutex_lock from one thread and then mutex_unlock from another is
not permitted. Replace the awkward mutex usage with a mutex and
condition variable.
llvm.org/pr18061
llvm-svn: 205900
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
SBTarget::AddModule(const char *path,
const char *triple,
const char *uuid_cstr,
const char *symfile);
If "symfile" was filled in, it would cause us to not correctly add the module. Same goes for:
SBTarget::AddModule(SBModuleSpec ...)
Where you filled in the symfile.
<rdar://problem/16529799>
llvm-svn: 205750
This fix reduces the stack size of SymbolFileDWARF::ParseType(). It seems that clang is not very good at sharing locations on the stack with local variables in large functions that have many blocks and each variable gets unique locations. The reduction in size was done by:
1 - removing some large locals that were default constructed by not used
2 - Placing some larger local variables into std::unique_ptr<> to make them on the heap
3 - removing local variables there were large and being populated but not being used
4 - reducing the size of some typedefs to llvm::SmallVector<T, N> so that N wasn’t excessively large
<rdar://problem/16431645>
llvm-svn: 205640
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
Greg Clayton