Commit Graph

579 Commits

Author SHA1 Message Date
Greg Clayton 52c3a07ece Revert Xcode run argument settings that were accidentally checked in.
llvm-svn: 202447
2014-02-28 00:13:03 +00:00
Jim Ingham 1e9947a56d Move the libpanel dependency into the Libraries project folder.
llvm-svn: 201596
2014-02-18 19:22:13 +00:00
Jim Ingham a524a46fde Convert to codesigning by hand to work around bugs in Xcode cert verification.
llvm-svn: 201595
2014-02-18 19:11:49 +00:00
Greg Clayton e98008cc58 Fixed deadlocks that could occur when using python for breakpoints, operating system plugins, and other async python usage.
<rdar://problem/16054348>
<rdar://problem/16040833>

llvm-svn: 201372
2014-02-13 23:34:38 +00:00
Jason Molenda 2fd83355a8 Change the Mac OS X SystemRuntime plugin from using the placeholder
libldi library to collect extended backtrace information; switch
to the libBacktraceRecording library and its APIs.  Complete the
work of adding QueueItems to Queues and allow for the QueueItems
to be interrogated about their extended backtraces in turn.

There's still cleanup and documentation to do on this code but the
code is functional and I it's a good time to get the work-in-progress 
checked in.  
<rdar://problem/15314027> 

llvm-svn: 200822
2014-02-05 05:44:54 +00:00
Greg Clayton 44d937820b Merging the iohandler branch back into main.
The many many benefits include:
1 - Input/Output/Error streams are now handled as real streams not a push style input
2 - auto completion in python embedded interpreter
3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use
4 - it is now possible to use curses to drive LLDB (please try the "gui" command)

We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases.

llvm-svn: 200263
2014-01-27 23:43:24 +00:00
Jason Molenda 5f36c4beec Update the lldb version number in the xcode project files from 310.99.0 to 320.99.0.
llvm-svn: 198917
2014-01-10 06:12:10 +00:00
Enrico Granata b72a501d86 FormatNavigator has long stopped navigating anything - the generation of possible formatters matches is now done elsewhere
So, rename the class for what it truly is: a FormattersContainer
Also do a bunch of related text substitutions in the interest of overall naming clarity

llvm-svn: 197795
2013-12-20 09:38:13 +00:00
Greg Clayton 2553e49a5d Added missing header files to the Xcode project.
llvm-svn: 197527
2013-12-17 21:42:58 +00:00
Jason Molenda 5e8dce4dbf Add new Queue, QueueItem, Queuelist, SBQueue, SBQueueItem classes to represent
libdispatch aka Grand Central Dispatch (GCD) queues.  Still fleshing out the
documentation and testing of these but the overall API is settling down so it's
a good time to check it in.
<rdar://problem/15600370> 

llvm-svn: 197190
2013-12-13 00:29:16 +00:00
Greg Clayton d5944cd118 For logical backtrace work, lldb needs to track Module unloads etc & symoblicate an address based on a point in time
<rdar://problem/15314403> 

This patch adds a new lldb_private::SectionLoadHistory class that tracks what shared libraries were loaded given a process stop ID. This allows us to keep a history of the sections that were loaded for a time T. Many items in history objects will rely upon the process stop ID in the future.

llvm-svn: 196557
2013-12-06 01:12:00 +00:00
Greg Clayton 2ec3db36f5 Updated the build settings for lldb-platform and lldb-gdbserver to include libxml2.
llvm-svn: 196320
2013-12-03 21:12:28 +00:00
Greg Clayton fa3082e728 Fixed up the framework includes to all be done in the extra linker options. We had a mix where some were being included via Xcode GUI and some were done in the extra linker flags.
llvm-svn: 196309
2013-12-03 19:41:45 +00:00
Greg Clayton 5fb8f79738 Fixed internal code to not link against and code from "lldb/API/*".
lldb_private::Debugger was #including some "lldb/API" header files which causes tools (lldb-platform and lldb-gdbserver) that link against the internals only (no API layer) to fail to link depending on which calls were being used.

Also fixed the current working directory so that it gets set correctly for remote test suite runs. Now the remote working directory is set to: "ARCH/TESTNUM/..." where ARCH is the current architecture name and "TESTNUM" is the current test number. 

Fixed the "lldb-platform" and "lldb-gdbserver" to not warn about mismatched visibility settings by having each have their own exports file which contains nothing. This forces all symbols to not be exported, and also quiets the linker warnings.

llvm-svn: 196141
2013-12-02 19:35:49 +00:00
Jason Molenda 906f329724 Change lldb from building against a Python framework out of
the installed SDK to using the current OS installed headers/libraries.
This change is to address the removal of the Python framework
from the Mac OS X 10.9 (Mavericks) SDK, and is the recommended
workaround via https://developer.apple.com/library/mac/technotes/tn2328/_index.html

llvm-svn: 195557
2013-11-23 20:07:29 +00:00
Greg Clayton 833d1295f9 <rdar://problem/15540233>
SBPlatform.h was missing from built LLDB.framework, now it is fixed.

llvm-svn: 195517
2013-11-22 23:32:57 +00:00
Greg Clayton be94a04055 Start the correct host abstraction of process and thread.
Added a new "Host/Debug.h" which contains the pure virtual class definitions for NativeProcessProtocol and NativeThreadProtocol. These classes are host layer classes that, over time, every host that supports debugging will implement once.

Then the new "lldb-gdbserver" binary in the tools directory will be able to make a remote debugging binary from these native classes, and we will also be able to have a new lldb_private::Process class that implements native debugging using these classes.

So as soon as linux and MacOSX switch over to using this layer, everyone will get native and remote debugging.

This check-in is primarily to get the needed code in so that poeple can start trying to implement the NativeProcessProtocol and NativeThreadProtocol and use it in the GDBRemoteCommunicationServer class to implement a GDB server for remote debugging.

llvm-svn: 195369
2013-11-21 18:39:32 +00:00
Greg Clayton fbb7634934 Expose SBPlatform through the public API.
Example code:

remote_platform = lldb.SBPlatform("remote-macosx"); 
remote_platform.SetWorkingDirectory("/private/tmp")
debugger.SetSelectedPlatform(remote_platform)

connect_options = lldb.SBPlatformConnectOptions("connect://localhost:1111"); 
err = remote_platform.ConnectRemote(connect_options)
if err.Success():
    print >> result, 'Connected to remote platform:'
    print >> result, 'hostname: %s' % (remote_platform.GetHostname())
    src = lldb.SBFileSpec("/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework", False)
    dst = lldb.SBFileSpec()
    # copy src to platform working directory since "dst" is empty
    err = remote_platform.Install(src, dst);
    if err.Success():
        print >> result, '%s installed successfully' % (src)
    else:
        print >> result, 'error: failed to install "%s": %s' % (src, err)


Implemented many calls needed in lldb-platform to be able to install a directory that contains symlinks, file and directories.

The remote lldb-platform can now launch GDB servers on the remote system so that remote debugging can be spawned through the remote platform when connected to a remote platform.

The API in SBPlatform is subject to change and will be getting many new functions.

llvm-svn: 195273
2013-11-20 21:07:01 +00:00
Jason Molenda a7b5afa91b Commit a work-in-progress system runtime for Mac OS X which won't
do anything right now.  Add a few new methods to the Thread base
class which HistoryThread needs.  I think I updated all the 
CMakeLists files correctly for the new plugin.

llvm-svn: 194756
2013-11-15 00:17:32 +00:00
Greg Clayton f74cf86bc5 <rdar://problem/15172417>
Added two new GDB server packets to debugserver: "QSaveRegisterState" and "QRestoreRegiterState".

"QSaveRegisterState" makes the remote GDB server save all register values and it returns a save identifier as an unsigned integer. This packet can be used prior to running expressions to save all registers.

All registers can them we later restored with "QRestoreRegiterState:SAVEID" what SAVEID is the integer identifier that was returned from the call to QSaveRegisterState.

Cleaned up redundant code in lldb_private::Thread, lldb_private::ThreadPlanCallFunction.
Moved the lldb_private::Thread::RegisterCheckpoint into its own header file and it is now in the lldb_private namespace. Trimmed down the RegisterCheckpoint class to omit stuff that wasn't used (the stack ID).

Added a few new virtual methods to lldb_private::RegisterContext that allow subclasses to efficiently save/restore register states and changed the RegisterContextGDBRemote to take advantage of these new calls.

llvm-svn: 194621
2013-11-13 23:28:31 +00:00
Jason Molenda fa421639de Change lldb to build without the -fobjc-gc arg.
llvm-svn: 194371
2013-11-11 10:36:54 +00:00
Jason Molenda 02706c3216 Add History subclasses for Thread, Unwind, RegisterContext.
Still working out some of the details of these classes but 
I wanted to get the overall structure checked in.
<rdar://problem/15314068> 

llvm-svn: 194245
2013-11-08 04:59:54 +00:00
Jason Molenda eef510667b Add a new system runtime plugin type - just the top level
class, not any actual plugin implementation yet.
<rdar://problem/15314068> 

llvm-svn: 194044
2013-11-05 03:57:19 +00:00
Greg Clayton 19c8e78b86 <rdar://problem/15201312>
Inlined a copy of cxa_demangle.cpp from:

http://llvm.org/svn/llvm-project/libcxxabi/trunk/src/cxa_demangle.cpp

For systems that don't have demangling built into the system, and for systems that don't want to use the version that is installed. Defining LLDB_USE_BUILTIN_DEMANGLER in your build system allows you to use the built in demangler. This setting is curently automatically enabled for Windows builds.

llvm-svn: 193708
2013-10-30 18:42:59 +00:00
Greg Clayton 9b2349888f Added the ability to get the SDK path for a target using the platform plugins. If LLDB lives inside an Xcode.app bundle, it will select the SDK in the Xcode bundle, else it will use the currently selected Xcode.
Also added the DWARFDataExtractor classes to the Xcode project file.

llvm-svn: 193380
2013-10-24 22:54:08 +00:00
Jim Ingham 5010b6972c BreakpointResolverFileRegex.cpp wandered from the lldb-core target to the LLDB.framework target.
Put it back where it belongs.

llvm-svn: 192986
2013-10-18 17:05:45 +00:00
Sean Callanan 074c314ea0 Added the Windows platform to our .xcodeproj,
and alphabetized the contents of
Source:Plugins:Platform.  This fixes the Mac
OS X build.

llvm-svn: 192833
2013-10-16 19:40:50 +00:00
Greg Clayton dd88bfd092 Removed the -t options from linking flags to avoid having the linker print out all .o files it was linking with.
llvm-svn: 192372
2013-10-10 17:51:57 +00:00
Enrico Granata 4d93b8cdf3 <rdar://problem/14393032>
DumpValueObject() 2.0

This checkin restores pre-Xcode5 functionality to the "po" (expr -O) command:
- expr now has a new --description-verbosity (-v) argument, which takes either compact or full as a value (-v is the same as -vfull)
 When the full mode is on, "po" will show the extended output with type name, persistent variable name and value, as in
(lldb) expr -O -v -- foo
(id) $0 = 0x000000010010baf0 {
    1 = 2;
    2 = 3;
}

 When -v is omitted, or -vcompact is passed, the Xcode5-style output will be shown, as in
(lldb) expr -O -- foo
{
    1 = 2;
    2 = 3;
}

- for a non-ObjectiveC object, LLDB will still try to retrieve a summary and/or value to display
(lldb) po 5
5
-v also works in this mode
(lldb) expr -O -vfull -- 5
(int) $4 = 5 

On top of that, this is a major refactoring of the ValueObject printing code. The functionality is now factored into a ValueObjectPrinter class for easier maintenance in the future
DumpValueObject() was turned into an instance method ValueObject::Dump() which simply calls through to the printer code, Dump_Impl has been removed

Test case to follow

llvm-svn: 191694
2013-09-30 19:11:51 +00:00
Enrico Granata e2e220a805 <rdar://problem/14071463>
SVN r189964 provided a sample Python script to inspect unordered(multi){set|map} with synthetic children, contribued by Jared Grubb
This checkin converts that sample script to a C++ provider built into LLDB
A test case is also provided

llvm-svn: 190564
2013-09-12 00:48:47 +00:00
Virgile Bello e2607b50ea Add OptionParser.h
llvm-svn: 190063
2013-09-05 16:42:23 +00:00
Virgile Bello f792acb20f Use <atomic> instead of "llvm/Support/Atomic.h". Removed unused RefCounter class.
llvm-svn: 190062
2013-09-05 16:38:02 +00:00
Daniel Malea e0f8f574c7 merge lldb-platform-work branch (and assorted fixes) into trunk
Summary:
    This merge brings in the improved 'platform' command that knows how to
    interface with remote machines; that is, query OS/kernel information, push
    and pull files, run shell commands, etc... and implementation for the new
    communication packets that back that interface, at least on Darwin based
    operating systems via the POSIXPlatform class. Linux support is coming soon.

    Verified the test suite runs cleanly on Linux (x86_64), build OK on Mac OS
    X Mountain Lion.

    Additional improvements (not in the source SVN branch 'lldb-platform-work'):
    - cmake build scripts for lldb-platform
    - cleanup test suite
    - documentation stub for qPlatform_RunCommand
    - use log class instead of printf() directly
    - reverted work-in-progress-looking changes from test/types/TestAbstract.py that work towards running the test suite remotely.
    - add new logging category 'platform'

    Reviewers: Matt Kopec, Greg Clayton

    Review: http://llvm-reviews.chandlerc.com/D1493

llvm-svn: 189295
2013-08-26 23:57:52 +00:00
Jason Molenda 6c20dde756 Add Host/common/ProcessRunLock.cpp to the xcode project file so TOT sources build with xcode again.
llvm-svn: 189163
2013-08-24 03:42:38 +00:00
Jason Molenda 17da171f1a Bump version number to 310.99.0.
llvm-svn: 186304
2013-07-15 04:47:33 +00:00
Greg Clayton 2540a8a7bc Fixed GetModuleSpecifications() to work better overall:
- MachO files now correctly extract the UUID all the time
- More file size and offset verification done for universal mach-o files to watch for truncated files
- ObjectContainerBSDArchive now supports enumerating all objects in BSD archives (.a files)
- lldb_private::Module() can not be properly constructed using a ModuleSpec for a .o file in a .a file
- The BSD archive plug-in shares its cache for GetModuleSpecifications() and the create callback
- Improved printing for ModuleSpec objects

llvm-svn: 186211
2013-07-12 22:07:46 +00:00
Jim Ingham f1715ab270 Get debugserver to call task_set_state to prime the control registers so that watchpoints
take for threads created while the program is running.  Remove the testcase skips from TestConcurrentEvents.py,
since they all pass now, and fix TestWatchpointMultipleThreads.py - which should have caught this problem -
so it doesn't artificially break on new thread creation before the watchpoint triggers.

llvm.org/pr16566
<rdar://problem/14383244>

llvm-svn: 186132
2013-07-11 23:20:35 +00:00
Greg Clayton 57ee306789 Huge change to clean up types.
A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error.

This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness.

llvm-svn: 186130
2013-07-11 22:46:58 +00:00
Greg Clayton 226cce2511 Added a way to extract the module specifications from a file. A module specification is information that is required to describe a module (executable, shared library, object file, ect). This information includes host path, platform path (remote path), symbol file path, UUID, object name (for objects in .a files for example you could have an object name of "foo.o"), and target triple. Module specification can be used to create a module, or used to add a module to a target. A list of module specifications can be used to enumerate objects in container objects (like universal mach files and BSD archive files).
There are two new classes:

lldb::SBModuleSpec
lldb::SBModuleSpecList

The SBModuleSpec wraps up a lldb_private::ModuleSpec, and SBModuleSpecList wraps up a lldb_private::ModuleSpecList.

llvm-svn: 185877
2013-07-08 22:22:41 +00:00
Daniel Malea 9a71a7d81b Revert commits that cause broken builds on GCC buildbots
- build fails due to PyCallable template definition inside an extern "C" scope

This commit reverts 185240, 184893 and 184608.

llvm-svn: 185560
2013-07-03 17:58:31 +00:00
Jason Molenda 45f6b1f935 Remove lldb's custom copy of the C++ demangler, used only on Mac
OS X.  Testsuite shows no change in results using the system runtime's
demangler.
<rdar://problem/12029914> 

llvm-svn: 185510
2013-07-03 04:52:51 +00:00
Greg Clayton ab70d5dbaa Added SymbolVendorELF to the wrong target (lldb-tool), now it is correctly added to lldb-core.
llvm-svn: 185388
2013-07-01 21:44:02 +00:00
Greg Clayton 8918b4b4a2 Fixed Xcode project to include SymbolVendorELF.
llvm-svn: 185386
2013-07-01 21:37:51 +00:00
Enrico Granata b4675a4e12 <rdar://problem/14266411>
The semi-unofficial way of returning a status from a Python command was to return a string (e.g. return "no such variable was found") that LLDB would pick as a clue of an error having happened

This checkin changes that:
- SBCommandReturnObject now exports a SetError() call, which can take an SBError or a plain C-string
- script commands now drop any return value and expect the SBCommandReturnObject ("return object") to be filled in appropriately - if you do nothing, a success will be assumed

If your commands were relying on returning a value and having LLDB pick that up as an error, please change your commands to SetError() through the return object or expect changes in behavior

llvm-svn: 184893
2013-06-25 23:43:28 +00:00
Enrico Granata c20eed4280 Lots of cleanup on the SWIG wrapping layer
Now, the way SWIG wrappers call into Python is through a utility PyCallable object, which overloads operator () to look like a normal function call
Plus, using the SBTypeToSWIGWrapper() family of functions, we can call python functions transparently as if they were plain C functions
Using this new technique should make adding new Python call points easier and quicker

The PyCallable is a generally useful facility, and we might want to consider moving it to a separate layer where other parts of LLDB can use it

llvm-svn: 184608
2013-06-21 23:27:16 +00:00
Enrico Granata c972c70e60 Change the SWIG wrappers to stop directly casting SB object to SWIG objects, and instead use a safer type-checked API (thanks templates)
Any time a SWIG wrapper needs a PyObject for an SB object, it now should call into SBTypeToSWIGWrapper<SBType>(SBType*)
If you try to use it on an SBType for which there is not an implementation yet, LLDB will fail to link - just add your specialization to python-swigsafecast.swig and rebuild

This is the first step in simplifying our SWIG Wrapper layer

llvm-svn: 184580
2013-06-21 18:57:30 +00:00
Jim Ingham 8c8c6fab4c Make the lldb "Release" configuration use the same llvm build "Release+Asserts" as the lldb "Debug" configuration.
No need to rebuild llvm and remove asserts to build the local optimized lldb.

llvm-svn: 184243
2013-06-18 21:44:59 +00:00
Enrico Granata 8ca77852f4 Removing the lldb-perf file group from our Xcode project
This is in a separate project now so this duplication is unnecessary and some referenced files were also dangling after a rename

llvm-svn: 184209
2013-06-18 17:15:32 +00:00
Enrico Granata 7594f14f7d <rdar://problem/14134716>
This is a rewrite of the command history facility of LLDB

It takes the history management out of the CommandInterpreter into its own CommandHistory class
It reimplements the command history command to allow more combinations of options to work correctly (e.g. com hist -c 1 -s 5)
It adds a new --wipe (-w) option to command history to allow clearing the history on demand
It extends the lldbtest runCmd: and expect: methods to allow adding commands to history if need be
It adds a test case for the reimplemented facility

llvm-svn: 184140
2013-06-17 22:51:50 +00:00
Enrico Granata 2e35cb7508 <rdar://problem/13988982>
LLDB API versioning
This checkin makes the LLDB API versioned
We are starting at version 1.0 and will then revise and update the API from there
Further details:
 API versioning
---------------------------------

The LLDB API is versioned independently of the LLDB source base
Our API version numbers are composed of a major and a minor number

The major number means a complete and stable revision of the API. Major numbers are compatibility breakers
(i.e. when we change the API major number, there is no promise of compatibility with the previous major version
 and we are free to remove and/or change any APIs)
Minor numbers are a work-in-progress evolution of the API. APIs will not be removed or changed across minor versions
(minors do not break compatibility). However, we can deprecate APIs in minor versions or add new APIs in minor versions
A deprecated API is supposedly going to be removed in the next major version and will generate a warning if used
APIs we add in minor versions will not be removed (at least until the following major) but they might theoretically be deprecated
in a following minor version
Users are discouraged from using the LLDB version number to test for API features and should instead use the API version checking
as discussed below

 API version checking
---------------------------------

You can (optionally) sign into an API version checking feature
To do so you need to define three macros:
LLDB_API_CHECK_VERSIONING - define to any value (or no value)
LLDB_API_MAJOR_VERSION_WANTED - which major version of the LLDB API you are targeting
LLDB_API_MINOR_VERSION_WANTED - which minor version of the LLDB API you are targeting

If these macros exist - LLDB will enable version checking of the public API

If LLDB_API_MAJOR_VERSION is not equal to LLDB_API_MAJOR_VERSION_WANTED we will immediately halt your compilation with an error
This is by design, since we do not make any promise of compatibility across major versions - if you really want to test your luck, disable the versioning altogether

If the major version test passes, you have signed up for a specific minor version of the API
Whenever we add or deprecate an API in a minor version, we will mark it with either
LLDB_API_NEW_IN_DOT_x - this API is new in LLDB .x
LLDB_API_DEPRECATED_IN_DOT_x - this API is deprecated as of .x

If you are using an API new in DOT_x
 if LLDB_API_MINOR_VERSION_WANTED >= x then all is well, else you will get a compilation error
  This is meant to prevent you from using APIs that are newer than whatever LLDB you want to target

If you are using an API deprecated in DOT_x
 if LLDB_API_MINOR_VERSION_WANTED >= x then you will get a compilation warning, else all is well
 This is meant to let you know that you are using an API that is deprecated and might go away

 Caveats
---------------------------------

Version checking only works on clang on OSX - you will get an error if you try to enable it on any other OS/compiler
If you want to enable version checking on other platforms, you will need to define appropriate implementations for
LLDB_API_IMPL_DEPRECATED and LLDB_API_IMPL_TOONEW and any other infrastructure your compiler needs for this purpose

We have no deprecation-as-error mode

There is no support for API versioning in Python

We reserve to use macros whose names begin with LLDB_API_ and you should not use them in your source code as they might conflict
with present or future macro names we are using to implement versioning


For API implementors:
If you need to add a new public API call, please remember to add the LLDB_API_NEW_IN_DOT_x marker in the header file
and when you are done with adding stuff, to also update LLDB_API_MINOR_VERSION
If you want to remove a function, deprecate it first, by using LLDB_API_DEPRECATED_IN_DOT_x
and when you are done with deprecating stuff, to also update LLDB_API_MINOR_VERSION
A new major version (LLDB_API_MAJOR_VERSION++) is your only chance to remove and/or change API calls
but is probably quite a big deal and you might want to consider deprecating the existing calls for a while
before doing your changes

A couple more caveats:
Currently, the lldb-tool does NOT use the version checking feature. It would be a nice future improvement to make it do that, once we have proper version checking on other OSs
APIs marked as deprecated by a comment in the source are still deprecated just that way. A good purpose for API 1.1 might be to deprecate them with appropriate markers

llvm-svn: 183244
2013-06-04 18:57:09 +00:00