Commit Graph

799 Commits

Author SHA1 Message Date
Todd Fiala 45557e34d9 Added real editline tests.
These are two simple tests that make sure single line and
multiline content are processed and received by Editline.cpp.

Fancier tests to come...

llvm-svn: 251681
2015-10-30 02:54:52 +00:00
Todd Fiala 15c0fbaae1 Rename argdumper to lldb-argdumper
http://reviews.llvm.org/D14169

llvm-svn: 251616
2015-10-29 05:07:12 +00:00
Jason Molenda a26a1eff93 Xcode suggested enabling a "no common blocks" warning
(whatever that is) and wanted to clean up some duplicated
entries in the project files.  

llvm-svn: 251586
2015-10-29 00:21:14 +00:00
Sean Callanan b731b89228 Removed an unecessary code-signing phase on lldb-tool.
llvm-svn: 251550
2015-10-28 20:07:46 +00:00
Sean Callanan c3e3144df2 Don't codesign lldbserver if debugserver codesigning is disabled, because it
probably won't work.

llvm-svn: 251527
2015-10-28 17:14:27 +00:00
Todd Fiala 528a30d62c Xcode: added lldb-gtest target to build and run the gtests in the unittests directory.
Also added a placeholder Editline gtest for some code that I'll add as soon
as I make sure this addition doesn't break any of the build bots.

This change also introduces some Xcode user-defined variables that I've used
to attempt to isolate the way Python is integrated into the build.  I don't have
the rest of LLDB using it yet, I'm using the gtests as my guinea pig on that.
Currently these are:
PYTHON_FRAMEWORK_PATH
PYTHON_VERSION_MAJOR
PYTHON_VERSION_MINOR

I will convert the rest over to it after this gets a little time to bake
and any kinks are worked out of it.

llvm-svn: 251261
2015-10-25 21:42:35 +00:00
Todd Fiala a80113a5ff Added some top-level unittests files that I missed in the last check-in.
I am also letting a debugserver-related project entry slide in
since Xcode seems to insist on inserting it, and when I remove it
the new files don't show up.

llvm-svn: 251243
2015-10-25 16:53:08 +00:00
Todd Fiala 3f1085d538 Add lldb/unittests files to the Xcode lldb project.
llvm-svn: 251240
2015-10-25 16:22:46 +00:00
Jason Molenda 76a2d615ad Move the launch-as-root xpc service from lldb to xcode, to
make it easier to run hand-built lldb roots and retain those
entitlements.  This is currently only used by Xcode; command
line lldb doesn't expose the SBLaunchInfo::SetUserID()
launch option.

<rdar://problem/23154486> 

llvm-svn: 250981
2015-10-22 04:17:26 +00:00
Oleksiy Vyalov 9fe526c2e7 Add domain socket support to gdb-remote protocol and lldb-server.
http://reviews.llvm.org/D13881

llvm-svn: 250933
2015-10-21 19:34:26 +00:00
Tamas Berghammer ccb367609b Add a new task pool class to LLDB
The purpose of the class is to make it easy to execute tasks in parallel

Basic design goals:
* Have a very lightweight and easy to use interface where a list of
  lambdas can be executed in parallel
* Use a global thread pool to limit the number of threads used
  (std::async don't do it on Linux) and to eliminate the thread creation
  overhead
* Destroy the thread currently not in use to avoid the confusion caused
  by them during debugging LLDB

Possible future improvements:
* Possibility to cancel already added, but not yet started tasks
* Parallel for_each implementation
* Optimizations in the thread creation destroyation code

Differential revision: http://reviews.llvm.org/D13727

llvm-svn: 250820
2015-10-20 12:42:05 +00:00
Sean Callanan 6681041d70 Added the concept of a Read-Eval-Print-Loop to LLDB.
A REPL takes over the command line and typically treats input as source code.
REPLs can also do code completion.  The REPL class allows its subclasses to
implement the language-specific functionality without having to know about the
IOHandler-specific internals.

Also added a PluginManager-based way of getting to a REPL given a language and
a target.

Also brought in some utility code and expression options that are useful for
REPLs, such as line offsets for expressions, ANSI terminal coloring of errors,
and a few IOHandler convenience functions.

llvm-svn: 250753
2015-10-19 23:11:07 +00:00
Enrico Granata c8e7649a19 Let Language plugins vend a default DeclPrintingHelper in case a custom one is not specified for the specific invocation
llvm-svn: 250744
2015-10-19 22:04:25 +00:00
Oleksiy Vyalov e98628cecb Split Socket class into Tcp/Udp/DomainSocket subclasses.
http://reviews.llvm.org/D13754

llvm-svn: 250474
2015-10-15 23:54:09 +00:00
Ravitheja Addepally 4069730c75 Testcase and fix for bug 24074
Summary:
In bug 24074, the type information is not shown
correctly. This commit includes the following -
-> Changes for displaying correct type based on
current lexical scope for the command "image
lookup -t"

-> The corresponding testcase.

-> This patch was reverted due to segfaults in
FreeBSD and Mac, I fixed the problems for both now.

Reviewers: emaste, granata.enrico, jingham, clayborg

Differential Revision: http://reviews.llvm.org/D13290

llvm-svn: 249673
2015-10-08 09:45:41 +00:00
Ryan Brown 07a1c459f2 Create GoLanguageRuntime.
GoLanguageRuntime supports finding the runtime type for Go interfaces.

llvm-svn: 249456
2015-10-06 20:29:31 +00:00
Enrico Granata 8a9a8f3940 Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be
This is a NFC commit that is essentially plumbing the new currency through the system

llvm-svn: 249366
2015-10-06 01:02:47 +00:00
Enrico Granata 7de855c6d9 Add hooks that enable NSSet, NSDictionary and NSString formatting to apply to other types beyond the well-known ones
This is meant to support languages that can do some sort of bridging from<-->to these ObjC types via types that statically vend themselves as Cocoa types, but dynamically have an implementation that does not match any of our well-known types, but where an introspecting formatter can be vended by the bridged language

llvm-svn: 249185
2015-10-02 20:59:58 +00:00
Tamas Berghammer 150c87c859 Fix xcode build after rL248903
llvm-svn: 248908
2015-09-30 14:55:08 +00:00
Sean Callanan 6d874ee31a Moved ClangExpressionHelper.h into the Clang expression parser plug-in.
llvm-svn: 248631
2015-09-25 22:47:07 +00:00
Sean Callanan 4dbb271fcc Moved more Clang-specific parts of the expression parser into the Clang plugin.
There are still a bunch of dependencies on the plug-in, but this helps to
identify them.
There are also a few more bits we need to move (and abstract, for example the
ClangPersistentVariables).

llvm-svn: 248612
2015-09-25 20:35:58 +00:00
Enrico Granata e5ffa089cc Revert 248366 "Testcase and fix for bug 24074"
This commit introduced regressions in several test cases on FreeBSD and Mac OS X

llvm-svn: 248421
2015-09-23 19:32:56 +00:00
Tamas Berghammer edf1465a56 Fix xcode build after r248366
llvm-svn: 248373
2015-09-23 11:00:35 +00:00
Sean Callanan 476d252846 Updated the Xcode build to reflect lldb-mi's dependency on LLVM.
llvm-svn: 247909
2015-09-17 18:03:26 +00:00
Ryan Brown 65d4d5c3c6 Add an OperatingSystem plugin to support goroutines
The Go runtime schedules user level threads (goroutines) across real threads.
This adds an OS plugin to create memory threads for goroutines.
It supports the 1.4 and 1.5 go runtime.

Differential Revision: http://reviews.llvm.org/D5871

llvm-svn: 247852
2015-09-16 21:20:44 +00:00
Tamas Berghammer 1f5e4483a4 Add support for the DWARFLocationList used by split-dwarf
Split-dwarf uses a different header format to specify the address range
for the elements of the location lists.

Differential revision: http://reviews.llvm.org/D12880

llvm-svn: 247789
2015-09-16 12:37:06 +00:00
Greg Clayton 64277a9e27 Fix Xcode project by adding CompilerDecl.cpp and .h.
llvm-svn: 247756
2015-09-16 00:03:14 +00:00
Jim Ingham 151c032c86 This patch makes Clang-independent base classes for all the expression types that lldb currently vends.
Before we had:

ClangFunction
ClangUtilityFunction
ClangUserExpression

and code all over in lldb that explicitly made Clang-based expressions. This patch adds an Expression 
base class, and three pure virtual implementations for the Expression kinds:

FunctionCaller
UtilityFunction
UserExpression

You can request one of these expression types from the Target using the Get<ExpressionType>ForLanguage. 
The Target will then consult all the registered TypeSystem plugins, and if the type system that matches 
the language can make an expression of that kind, it will do so and return it.

Because all of the real expression types need to communicate with their ExpressionParser in a uniform way, 
I also added a ExpressionTypeSystemHelper class that expressions generically can vend, and a ClangExpressionHelper 
that encapsulates the operations that the ClangExpressionParser needs to perform on the ClangExpression types. 
Then each of the Clang* expression kinds constructs the appropriate helper to do what it needs.

The patch also fixes a wart in the UtilityFunction that to use it you had to create a parallel FunctionCaller 
to actually call the function made by the UtilityFunction. Now the UtilityFunction can be asked to vend a 
FunctionCaller that will run its function. This cleaned up a lot of boiler plate code using UtilityFunctions.

Note, in this patch all the expression types explicitly depend on the LLVM JIT and IR, and all the common 
JIT running code is in the FunctionCaller etc base classes. At some point we could also abstract that dependency 
but I don't see us adding another back end in the near term, so I'll leave that exercise till it is actually necessary.

llvm-svn: 247720
2015-09-15 21:13:50 +00:00
Greg Clayton 73781e7557 Fix the Xcode project to compile Cocoa.cpp instead of Coca.cpp.
llvm-svn: 247631
2015-09-14 22:57:25 +00:00
Ryan Brown 57bee1edfc Add a TypeSystem for Go
Add GoASTContext and DWARFASTParserGo to support go.

Differential Revision: http://reviews.llvm.org/D12585

llvm-svn: 247629
2015-09-14 22:45:11 +00:00
Enrico Granata 170c395e70 Move Objective-C data formatters to the Objective-C language plugin where they belong
llvm-svn: 247627
2015-09-14 22:18:32 +00:00
Bruce Mitchener cf1baae6b8 [lldb-mi] Remove MIUtilSystem*.
Summary:
This platform-specific code wasn't fully implemented and wasn't
actually needed. There was one call for the log file path and
that has been addressed.

This lets us also remove an error message from MICmnLogMediumFile
as it is no longer used.

Reviewers: ki.stfu, domipheus, abidh

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D12764

llvm-svn: 247388
2015-09-11 04:50:44 +00:00
Greg Clayton 140038a4ee Fix the build-llvm.pl to not create one monster .a file from all of the llvm and clang .a files. We now just make a file list which we pass to the linker.
llvm-svn: 247202
2015-09-09 22:35:25 +00:00
Tamas Berghammer eb882fc1f8 Add basic fission support to SymbolFileDWARF
* Create new dwo symbol file class
* Add handling for .dwo sections
* Change indexes in SymbolFileDWARF to store compile unit offset next to
  DIE offset
* Propagate queries from dwarf compile unit to the dwo compile unit
  where applicable

Differential revision: http://reviews.llvm.org/D12291

llvm-svn: 247132
2015-09-09 10:20:48 +00:00
Enrico Granata 33e97e63a5 Move the C++ data formatters to the C++ language plugin
llvm-svn: 246873
2015-09-04 21:01:18 +00:00
Sean Callanan 7a518c3dab I accidentally committed some project-file changes. Undid those.
llvm-svn: 246872
2015-09-04 20:54:25 +00:00
Sean Callanan bc8ac34e61 This patch separates the generic portion of ClangExpressionVariable, which
stores information about a variable that different parts of LLDB use, from the
compiler-specific portion that only the expression parser cares about.

http://reviews.llvm.org/D12602

llvm-svn: 246871
2015-09-04 20:49:51 +00:00
Enrico Granata 419d79189f Nuke CXXFormatterFunctions.cpp - split the contents of it across different files, so that things are better organized along the C++/ObjC line
This is preparatory work for moving these formatters into language categories

llvm-svn: 246827
2015-09-04 00:33:51 +00:00
Bruce Mitchener 3921fc7de7 Only export public symbols with the cmake build.
Summary:
This also moves the xcode support files to be near or the same
as the ones used for cmake.

The source/API/liblldb.xcodes.exports differs from the
source/API/liblldb.exports in that one contains the actual
symbol names (_ prefixed) while the other contains the symbol
names as they are in the code. The liblldb.exports file is
preprocessed by the cmake scripts into the correct per-platform
file needed (like a linker script on Linux).

This is not enabled on Windows as Windows doesn't use the same
name mangling and so it won't be valid there. Also, this is handled
already in a different way on Windows (via dll exports).

Reviewers: emaste, clayborg, labath, chaoren

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D12599

llvm-svn: 246822
2015-09-04 00:00:41 +00:00
Enrico Granata d87cc31960 CXXFormatterFunctions.{h|cpp} is not a good thing to have around, so start splitting stuff in different files in preparation for removing it and factoring formatters to the plugins where they belong
llvm-svn: 246743
2015-09-03 01:29:42 +00:00
Sean Callanan e33724f371 In preparation for factoring persistent variables into a generic part and a
Clang-specific part, create the ExpressionVariable source/header file and
move ClangExpressionVariable into the Clang expression parser plugin.

It is expected that there are some ugly #include paths... these will be resolved
by either (1) making that code use generic expression variables (once they're
separated appropriately) or (2) moving that code into a plug-in, often
the expression parser plug-in.

llvm-svn: 246737
2015-09-03 00:35:46 +00:00
Sean Callanan 7ddb35e996 Added a skeleton plugin for the Clang expression parser, so I can start factoring stuff into it.
llvm-svn: 246677
2015-09-02 16:59:02 +00:00
Sean Callanan 873a78e76c Added an ExpressionParser plugin skeleton with nothing in it (yet).
llvm-svn: 246674
2015-09-02 16:49:14 +00:00
Enrico Granata df7e79e646 Move the functions that FormatManager uses to actually load formatters into their own file
These are useful helpers over the low-level API of the FormattersContainer, and since we're actually going to start moving formatters into plugins, it makes sense to simplify things

llvm-svn: 246612
2015-09-02 01:21:31 +00:00
Enrico Granata 980c0484c5 Add support for language plugins to provide data formatters (second attempt)
Historically, data formatters all exist in a global repository (the category map)
On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex)

This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on
The advantages of this are:
a) language formatters only get created when they might apply
b) formatters for a language are clearly owned by the matching language plugin

The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager
In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters

No formatters are moved as part of this change, so practically speaking this is NFC

llvm-svn: 246568
2015-09-01 18:22:39 +00:00
Pavel Labath f15a16704b Revert "Add support for language plugins to provide data formatters"
This reverts r246515 (and related cmake fixes) as it breaks all libcxx tests.

llvm-svn: 246536
2015-09-01 09:02:54 +00:00
Enrico Granata 2233895a3b Add support for language plugins to provide data formatters
Historically, data formatters all exist in a global repository (the category map)
On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex)

This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on
The advantages of this are:
a) language formatters only get created when they might apply
b) formatters for a language are clearly owned by the matching language plugin

The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager
In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters

No formatters are moved as part of this change, so practically speaking this is NFC

llvm-svn: 246515
2015-09-01 01:01:48 +00:00
Greg Clayton 261ac3f4b5 Made a new abstract class named "DWARFASTParser" which lives in "source/Plugins/SymbolFile/DWARF":
class DWARFASTParser
{
public:
    virtual ~DWARFASTParser() {}

    virtual lldb::TypeSP
    ParseTypeFromDWARF (const lldb_private::SymbolContext& sc,
                        const DWARFDIE &die,
                        lldb_private::Log *log,
                        bool *type_is_new_ptr) = 0;


    virtual lldb_private::Function *
    ParseFunctionFromDWARF (const lldb_private::SymbolContext& sc,
                            const DWARFDIE &die) = 0;

    virtual bool
    CompleteTypeFromDWARF (const DWARFDIE &die,
                           lldb_private::Type *type,
                           lldb_private::CompilerType &clang_type) = 0;

    virtual lldb_private::CompilerDeclContext
    GetDeclContextForUIDFromDWARF (const DWARFDIE &die) = 0;

    virtual lldb_private::CompilerDeclContext
    GetDeclContextContainingUIDFromDWARF (const DWARFDIE &die) = 0;

};

We have one subclass named DWARFASTParserClang that implements all of the clang specific AST type parsing. This keeps all DWARF parsing in the DWARF plug-in. Moved all of the DWARF parsing code that was in ClangASTContext over into DWARFASTParserClang.

lldb_private::TypeSystem classes no longer have any DWARF parsing functions in them, but they can hand out a DWARFASTParser:

virtual DWARFASTParser *
GetDWARFParser ()
{
    return nullptr;
}

This keeps things clean and makes for easy merging when we have different AST's for different languages.

llvm-svn: 246242
2015-08-28 01:01:03 +00:00
Enrico Granata 5f9d310640 Add a new type of plugin: Language plugin
The Language plugin is menat to answer language-specific questions that are not bound to the existence of a process. Those are still the domain of the LanguageRuntime plugin

The Language plugin will, instead, answer questions such as providing language-specific data formatters or expression evaluation

At the moment, the interface is hollowed out, and empty do-nothing plugins have been setup for ObjC, C++ and ObjC++

llvm-svn: 246212
2015-08-27 21:33:50 +00:00
Enrico Granata db3d58b94a Remove class Language - the only thing it was actually being used for is provided by LanguageRuntime already
llvm-svn: 246177
2015-08-27 18:18:49 +00:00