Previously, CMake was invoking the test runner and not specifying
what architecture to use when building test executables. The
Makefiles for the test executables then had logic to choose x64
by default. This doesn't work on Windows because the test compiler
would then try to link against the 64-bit MSVCRT and not find them
since only the 32-bit MSVCRT was in the path.
This patch addresses this by figuring out, at CMake time, whether
or not you are building LLDB with a 64 or 32-bit toolchain. Then,
it explicitly passes this value to the test runner, causing the
test runner to build tests whose architecture matches that of LLDB
itself. This can still be overridden by setting the CMake variable
LLDB_TEST_EXECUTABLE_ARCH=(x64|x86)
llvm-svn: 214443
DW_OP_fbreg(N) DW_OP_piece(4) DW_OP_fbreg(M) DW_OP_piece(8)
DW_OP_fbreg(N) DW_OP_piece(4) DW_OP_piece(8)
The first grabs 4 bytes from FP+N followed by 8 bytes from FP+M, the second grabs 4 bytes from FP+N followed by zero filling 8 bytes which are unavailable. Of course regiters are stuff supported:
DW_OP_reg3 DW_OP_piece(4) DW_OP_reg8 DW_OP_piece(8)
The fix does the following:
1 - don't push the full piece value onto the stack, keep it on the side
2 - fill zeros for DW_OP_piece(N) opcodes that have nothing on the stack (instead of previously consuming the full piece that was pushed onto the stack)
3 - simplify the logic
<rdar://problem/16930524>
llvm-svn: 214415
PlatformDarwinKernel::GetGenericSDKDirectoriesToSearch
- /Library/Developer/KDKs where users may store
the kernel debug kits on their systems.
Change PlatformDarwinKernel::GetKextDirectoriesInSDK
to look in the root directory of places like
/Library/Developer/KDKs/KDK_10.10_14A298i.kdk
as well as the System/Library/Extensions subdir
in that directory (if it exists) and the
Library/Extensions subdir in that directory (if it
exists).
<rdar://problem/16568635>
llvm-svn: 214391
This is not bullet-proof, as you might end up running in a thread where you shouldn't, but the previous policy had the same drawback
Also, in cases where code-running formatters were being recursively applied, the previous policy caused deeper levels to fail, whereas this will at least get such scenarios to function
We might eventually want to consider disqualifying certain threads/frames for "viability", but I'd rather keep it simple until complexity is proven to be necessary
llvm-svn: 214337
Also fixed the host 32 and 64 bit arch to return "x86_64-apple-macosx" again instead of "x86_64-apple-" (unspecified OS) after recent changes.
<rdar://problem/17845078>
llvm-svn: 214223
This was causing core dumps on MacOSX and was not properly
cleaning up the state of the inferior before exiting.
The test was overriding def tearDown(), but failed to
call the base class after doing its own cleanup. This
essentially eliminated normal clean-up activity.
llvm-svn: 214138
This patch creates a simple ProcessWindows process plugin.
The only thing it knows how to do currently is create processes.
Differential Revision: http://reviews.llvm.org/D4681
llvm-svn: 214094
Assuming that the user's home directory is at ~ is incorrect on
Windows. This patch delegates the request to LLVM's support
library, which already provides a cross-platform implementation
of this function.
Differential Revision: http://reviews.llvm.org/D4674
llvm-svn: 214093
i386, i486, i486sx, and i686 are all indistinguishable as far as
PE/COFF files are concerned. This patch adds support for all of
these architectures to PlatformWindows.
Differential Revision: http://reviews.llvm.org/D4658
llvm-svn: 214092
The code had moved forward with changes for using ProcessLaunchInfo,
but the documentation still referred to arguments that no longer
get passed to these methods.
llvm-svn: 213965
This change has the practical effect of fixing some backtrace
scenarios that would fail with inferiors running on the Android Art
host-side JVM under Linux x86_64 on Ubuntu 14.04.
See this lldb-commits thread for more details:
http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140721/011988.html
Change by Tong Shen.
Reviewed by Jason Molenda.
Tested:
Ubuntu 14.04 x86_64, clang-3.5-built lldb.
MacOSX 10.10 Preview 4, Xcode 6 Beta 4-built lldb.
llvm-svn: 213914
The uint16_t cast truncated the magic value to 0x00000304, making the
first byte 0 (eByteOrderInvalid) on big endian hosts.
Reported by Justin Hibbits.
llvm-svn: 213861
GDBRemoteRegisterContext::ReadRegisterBytes and
GDBRemoteRegisterContext::WriteRegisterBytes to ensure we don't try
to read/write off the end of the register buffer. This should never
happen but we've had some target confusion in the past where it
did; adding the checks is prudent to avoid crashing here if it happens
again.
<rdar://problem/16450971>
<rdar://problem/16458182>
llvm-svn: 213829
to the remote side (QStartNoAckMode) - it may take a little longer
than normal to get a reply.
In debugserver, hardcode the priority for several threads so they
aren't de-prioritized when a user app is using system resources.
Also, set the names of the threads.
<rdar://problem/17509866>
llvm-svn: 213828
clang-format is a handy tool that formats code very intelligently. I'd
like to use it with LLDB but it requires a .clang-format file to inform
it about LLDB-specific formatting rules.
More information on these rules are here:
http://clang.llvm.org/docs/ClangFormatStyleOptions.html
Differential Revision: http://reviews.llvm.org/D4630
llvm-svn: 213823
File::SeekFromStart returns an off_t representing the position of the
file after seeking. This return value is always going to be one of two
values: the input or -1 in the case of failure.
ObjectFileMachO compares an expression of type off_t from the return of
File::SeekFromStart(segment.fileoff) and compares it for equality with
segment.fileoff.
The type of segment_command_64::fileoff is unsigned while off_t is
signed, comparing them emits a diagnostic under GCC.
Instead, we can just compare SeekFromSTart with -1 to see if we
successfully seeked.
Differential Revision: http://reviews.llvm.org/D4634
llvm-svn: 213822
We now catch the issue with a static_assert() at compile time and use llvm::array_lengthof(g_core_definitions) as well.
<rdar://problem/17767541>
llvm-svn: 213778
See the following llvm change for details:
r213743 | tnorthover | 2014-07-23 05:32:47 -0700 (Wed, 23 Jul 2014) | 9 lines
AArch64: remove arm64 triple enumerator.
This change fixes build breaks on Linux and MacOSX lldb.
llvm-svn: 213755
GCC emits a warning:
warning: enumeral and non-enumeral type in conditional expression [enabled by default]
which does not seem to have a flag to control it. Simply add an explicit cast
for the boolean value.
llvm-svn: 213715
This change enables lldb-platform for Linux. In addition, it does the following:
* fixes Host::GetLLDBPath() to work on Linux/*BSD for ePathTypeSupportExecutableDir-relative paths.
* adds more logging and comments around lldb-platform startup and remote lldb-platform usage.
* refactors lldb-platform remote-* support for Darwin and Linux into PlatformPOSIX. This, in theory, is the bulk of what is needed for *BSD to make remote connections to lldb-platform as well (although I haven't tested that yet). FreeBSD can make similar changes to their Platform* as was made here for PlatformLinux to pick up the rest of the bits.
* teaches GDBRemoteCommunication to use lldb-gdbserver for non-Apple hosts.
llvm-svn: 213707
reinterpret_cast may not convert a pointer-to-function to a
void-pointer. Take a detour through intptr_t and *then* convert to a
pointer-to-function.
This fixes a diagnostic emitted by GCC.
llvm-svn: 213696
printf's %p format specifier expects an argument of type void-pointer,
not type PyThreadState*. Fix this with a static_cast.
Differential Revision: http://reviews.llvm.org/D4632
llvm-svn: 213695
reinterpret_cast may not convert a pointer-to-function to a
void-pointer. Take a detour through intptr_t and *then* convert to a
pointer-to-function.
This silences a warning emitted by GCC when building LLDB.
Differential Revision: http://reviews.llvm.org/D4631
llvm-svn: 213693
reinterpret_cast may not convert a pointer-to-function to a
void-pointer. Take a detour through intptr_t and *then* convert to a
pointer-to-function.
This fixes a warning emitted by GCC.
Differential Revision: http://reviews.llvm.org/D4624
llvm-svn: 213692
GCC warns on reinterpret_cast expressions involving a void-pointer
source and a pointer-to-function destination. Take a detour through
intptr_t to silence it.
Differential Revision: http://reviews.llvm.org/D4626
llvm-svn: 213691
reinterpret_cast may not convert a pointer-to-function to a
void-pointer. Take a detour through intptr_t and *then* convert to a
pointer-to-function.
Differential Revision: http://reviews.llvm.org/D4627
llvm-svn: 213682
Platforms which don't use LLDB's built-in demangler don't use the
'mangled_length' variable. Instead, replace it's only use by an
expression it is equivalent to.
Differential Revision: http://reviews.llvm.org/D4625
llvm-svn: 213681
The new implementation is located in source/Core/FastDemangle.cpp. It’s fairly straightforward C code with a few basic C++ extensions. It should compile with little or no change on a variety of platforms, but of course it is still only useful for symbols that comply with the Itanium ABI mangling spec (plus a few Clang extensions.)
<rdar://problem/15397553> <rdar://problem/15794867>
llvm-svn: 213671
Currently, the test runner makes the assumption that it will run
commands through /bin/sh. This is obviously not true on Windows,
so this patch abstracts this logic out somewhat. Instead of
having the caller build the command string himself, the caller
will now pass in argument list of the form [[a, b], [c, d], ...]
which will get converted into a string of the form a b; c d or
a b && c d, depending on the platform.
Reviewed by: Todd Fiala
Differential Revision: http://reviews.llvm.org/D4590
llvm-svn: 213669
1) Preserve ref qualification state in a local variable while parsing a nested name. Previously, the state was recorded in the shared db reference and could therefore be overwritten when parsing multiple levels of nested names (e.g.: when a qualified name has qualified template args.)
2) Address an off-by-one error when testing whether or not a thunk is non-virtual. This resulted in the demangled identifying all thunks as non-virtual.
llvm-svn: 213591
LLDWrapPython.cpp is a generated file. This contains a double assignment to the
same value, which causes GCC to emit a warning about sequence point evaluation
causing a use-before-init. Simply silence the warning.
llvm-svn: 213575
result variable and use in in "Process::LoadImage" so that,
for instance, "process load" doesn't increment the return
variable number.
llvm-svn: 213440
lldb -P, which outputs its python path, works by using Host-layer
facilities to get information about the loaded python module. This
Host functionality was unimplemented on Windows, so this patch
implements it. Additionally, it removes a pexpect dependency from
the test runner and uses an equivalent invocation of subprocess.
Reviewed by: Todd Fiala
Differential Revision: http://reviews.llvm.org/D4548
llvm-svn: 213410
Fix the warning the correct way without making things crash when ENABLE_MUTEX_ERROR_CHECKING is non enabled.
<rdar://problem/17703039>
llvm-svn: 213394
99% of this CL is simply moving calls to "import pexpect" to a more
narrow scope - i.e. the function that actually runs a particular
test. This way the test suite can run on Windows, which doesn't have
pexpect, and the individual tests that use pexpect can be disabled on
a platform-specific basis.
Additionally, this CL fixes a few other cases of non-portability.
Notably, using "ps" to get the command line, and os.uname() to
determine the architecture don't work on Windows. Finally, this
also adds a stubbed out builder_win32 module.
The full test suite runs correctly on Windows after this CL, although
there is still some work remaining on the C++ side to fix one-shot
script commands from LLDB (e.g. script print "foo"), which currently
deadlock.
Reviewed by: Todd Fiala
Differential Revision: http://reviews.llvm.org/D4573
llvm-svn: 213343
This fixes all of the hidden ivar test cases and any case where we try to find the full definition of an objective C class.
This also means hidden ivars show up again.
<rdar://problem/15458957>
llvm.org/pr20270
llvm.org/pr20269
llvm.org/pr20272
llvm-svn: 213328
_lldb is built as an extension module on Windows. Normally to load
an extension module named 'foo', Python would look for the file
'foo.pyd'. However, when a debug interpreter is used, Python will
look for the file 'foo_d.pyd'. This change checks the build
configuration and creates the correct symlink name based on the
build configuration.
llvm-svn: 213306
- First, when logging, be helpful by printing
the real name of the class;
- Second, up the limit for number of classes
from 16k to 128k, and put in an assertion
(and better error handling when not in a
debug configuration) when we cross that
limit the next time.
<rdar://problem/17052976>
llvm-svn: 213218
Also track down the required binary by trying to locate the main executable module through LLDB's symbol and executable file locating code.
<rdar://problem/16570258>
llvm-svn: 213199
The problem was that we have an IOHandler thread that services the IOHandler stack. The command interepter is on the top of the stack and it receives a "expression ..." command, and it calls the IOHandlerIsComplete() callback in the command interpereter delegate which runs an expression. This causes the IOHandlerProcessSTDIO to be pushed, but since we are running the code from the IOHandler thread, it won't get run. When CTRL+C is pressed, we do deliver the interrupt to the IOHandlerProcessSTDIO::Interrupt() function, but it was always writing 'i' to the interrupt pipe, even if we weren't actively reading from the debugger input and the pipes. This fix works around the issue by directly issuing the async interrupt to the process if the process is running.
A longer term more correct fix would to be run the IOHandler thread and have it just do the determination of the input and when complete input is received, run the code that handles that input on another thread and syncronize with that other thread to detect when more input is desired. That change is too big to make right now, so this fix will tide us over until we can get there.
<rdar://problem/16556228>
llvm-svn: 213196
This value gets set to a max uint32_t value when there is no known limit; otherwise,
it is set to a value appropriate for the platform. For the moment, only
Linux, FreeBSD and NetBSD set it to 16. All other platforms set it to
the max uint32_t value.
Modifies the Process private state thread names to fit within a 16-character limit
when the max thread name length is <= 16. These guarantee that the thread names
can be distinguished within the first 16 characters. Prior to this change, those
threads had names in the final dotted name segment that were not distinguishable
within the first 16 characters.
llvm-svn: 213183
r213171 renames the 'clangRewriteCore' library to 'clangRewrite'.
This change simply updates the makefiles to reference the correct
library name.
llvm-svn: 213181
This change adds a member to the base test case for gdb-remote that
indicates whether a stub makes two X stop notification reports on kill
commands. This is set to true for debugserver tests.
The test for killing an attached process after it's first stop notification
has been modified to look at that flag and add an extra X packet matcher
so the "unmatched packet warning" doesn't get emitted for the second X on
MacOSX with debugserver.
I also broke those tests out of the monolithic TestLldbGdbServer mega test
case and put it in its own, new TestGdbRemoteKill.py file and test case.
Tested:
Ubuntu 14.04 x86_64, clang-3.5 built lldb, no test failures.
MacOSX 10.9.4, Xcode 6.0 Beta 3 built lldb, no test failures.
llvm-svn: 213166
This change comprises of additions and some minor changes in order that
"kalimba" is listed as a supported platform and that debugging any
kalimbas results in PlatformKalimba being associated with the target.
The changes are as follows:
* The PlatformKalimba implementation itself
* A tweak to ArchSpec
* .note parsing for Kalimba in ObjectFileELF.cpp
* Plugin registration
* Makefile additions
Change by Matthew Gardiner
Minor tweak for cmake and Xcode by Todd Fiala
Tested:
Ubuntu 14.04 x86_64, clang 3.5-built lldb, all tests pass.
MacOSX 10.9.4, Xcode 6.0 Beta 1-built lldb, all tests pass.
llvm-svn: 213158
Fixed the test case to use a runtime function prototype that will be correct ([NSString stringWithCString: "new"]) instead of one that won't (expression str = [NSString stringWithFormat: @"%cew", 'N']). The runtime doesn't track vararg functions correctly so we can't reconstitute the function correctly.
Also fixed some expressions that used "str_id" whose type was "id" and do the necessary casting since "id" doesn't have any methods.
llvm-svn: 213113
LinuxThread.cpp
LinuxThread.h
NativeRegisterContext.h
ProcessLinux.cpp
ProcessLinux.h
ProcessMonitor.cpp
ProcessMonitor.h
Were inserted in the CopyFiles phase of the "desktop" aggregate target. That caused them to get
copied to /usr/shared/man/man1 on install, which isn't right. Not sure why they were there...
I removed them. If this was supposed to achieve some other purpose, we should discuss how to do
that correctly on the mailing list.
<rdar://problem/17642262>
llvm-svn: 213094
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
Matthew Gardiner