Commit Graph

762 Commits

Author SHA1 Message Date
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
Greg Clayton 6071e6fc94 Major DWARF cleanup.
Added a new class called DWARFDIE that contains a DWARFCompileUnit and DWARFDebugInfoEntry so that these items always stay together.

There were many places where we just handed out DWARFDebugInfoEntry pointers and then use them with a compile unit that may or may not be the correct one. Clients outside of DWARFCompileUnit and DWARFDebugInfoEntry should all be dealing with DWARFDIE instances instead of playing with DWARFCompileUnit/DWARFDebugInfoEntry pairs manually.

This paves to the way for some modifications that are coming for DWO.

llvm-svn: 246100
2015-08-26 22:57:51 +00:00
Greg Clayton 99558cc424 Final bit of type system cleanup that abstracts declaration contexts into lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions.
Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files.

Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types.

Bulk renames for things that used to return a ClangASTType which is now CompilerType:

    "Type::GetClangFullType()" to "Type::GetFullCompilerType()"
    "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()"
    "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()"
    "Value::GetClangType()" to "Value::GetCompilerType()"
    "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)"
    "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()"
    many more renames that are similar.

llvm-svn: 245905
2015-08-24 23:46:31 +00:00
Greg Clayton 6dc8d583b9 More abstraction to get almost all clang specific DWARF parsing code into ClangASTContext.
llvm-svn: 245376
2015-08-18 22:32:36 +00:00
Jason Molenda a18f7071c2 A messy bit of cleanup: Move towards more descriptive names
for eh_frame and stabs register numberings.  This is not
complete but it's a step in the right direction.  It's almost
entirely mechanical.

lldb informally uses "gcc register numbering" to mean eh_frame.
Why?  Probably because there's a notorious bug with gcc on i386
darwin where the register numbers in eh_frame were incorrect.
In all other cases, eh_frame register numbering is identical to
dwarf.

lldb informally uses "gdb register numbering" to mean stabs.
There are no official definitions of stabs register numbers
for different architectures, so the implementations of gdb
and gcc are the de facto reference source.

There were some incorrect uses of these register number types
in lldb already.  I fixed the ones that I saw as I made
this change.

This commit changes all references to "gcc" and "gdb" register
numbers in lldb to "eh_frame" and "stabs" to make it clear 
what is actually being represented.

lldb cannot parse the stabs debug format, and given that no
one is using stabs any more, it is unlikely that it ever will.
A more comprehensive cleanup would remove the stabs register
numbers altogether - it's unnecessary cruft / complication to
all of our register structures.

In ProcessGDBRemote, when we get register definitions from
the gdb-remote stub, we expect to see "gcc:" (qRegisterInfo)
or "gcc_regnum" (qXfer:features:read: packet to get xml payload).
This patch changes ProcessGDBRemote to also accept "ehframe:"
and "ehframe_regnum" from these remotes.

I did not change GDBRemoteCommunicationServerLLGS or debugserver
to send these new packets.  I don't know what kind of interoperability
constraints we might be working under.  At some point in the future
we should transition to using the more descriptive names.

Throughout lldb we're still using enum names like "gcc_r0" and "gdb_r0",
for eh_frame and stabs register numberings.  These should be cleaned
up eventually too.

The sources link cleanly on macosx native with xcode build.  I
don't think we'll see problems on other platforms but please let
me know if I broke anyone.

llvm-svn: 245141
2015-08-15 01:21:01 +00:00
Greg Clayton a1e5dc86a6 ClangASTType is now CompilerType.
This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc).

llvm-svn: 244689
2015-08-11 22:53:00 +00:00
Greg Clayton d8d4a57b37 First step in getting LLDB ready to support multiple different type systems.
This is the work done by Ryan Brown from http://reviews.llvm.org/D8712 that makes a TypeSystem class and abstracts types to be able to use a type system.

All tests pass on MacOSX and passed on linux the last time this was submitted. 

llvm-svn: 244679
2015-08-11 21:38:15 +00:00
Jason Molenda 3874ee6869 Bump the version # in the xcode proj file from major number 340 to 350.
The SB API for major version 340 won't be changing any more.

llvm-svn: 243943
2015-08-04 03:14:49 +00:00
Zachary Turner 2c1f46dcc6 Convert the ScriptInterpreter system to a plugin-based one.
Previously embedded interpreters were handled as ad-hoc source
files compiled into source/Interpreter.  This made it hard to
disable a specific interpreter, or to add support for other
interpreters and allow the developer to choose which interpreter(s)
were enabled for a particular build.

This patch converts script interpreters over to a plugin-based system.
Script interpreters now live in source/Plugins/ScriptInterpreter, and
the canonical LLDB interpreter, ScriptInterpreterPython, is moved there
as well.

Any new code interfacing with the Python C API must live in this location
from here on out.  Additionally, generic code should never need to
reference or make assumptions about the presence of a specific interpreter
going forward.

Differential Revision: http://reviews.llvm.org/D11431
Reviewed By: Greg Clayton

llvm-svn: 243681
2015-07-30 20:28:07 +00:00
Ed Maste 5bfed4a77f Update xcode for r243427
llvm-svn: 243432
2015-07-28 16:11:12 +00:00
Enrico Granata ccc025b9fe Add an Either<T,U> type to lldb_utility which represents a type-safe payload of either one type or another, à la Haskell
llvm-svn: 242867
2015-07-22 02:06:37 +00:00
Jason Molenda 86a86cf725 Build ValueObjectConstResultCast.cpp.
llvm-svn: 242379
2015-07-16 03:38:17 +00:00
Ewan Crawford cf388ccfbc Fix LLDB Xcode build broken in r242137
llvm-svn: 242143
2015-07-14 13:29:03 +00:00
Ewan Crawford 90ff791141 Expression evaluation, a new ThreadPlanCallFunctionUsingABI for executing a function call on target via register manipulation
For Hexagon we want to be able to call functions during debugging, however currently lldb only supports this when there is JIT support. 
Although emulation using IR interpretation is an alternative, it is currently limited in that it can't make function calls.

In this patch we have extended the IR interpreter so that it can execute a function call on the target using register manipulation. 
To do this we need to handle the Call IR instruction, passing arguments to a new thread plan and collecting any return values to pass back into the IR interpreter. 

The new thread plan is needed to call an alternative ABI interface of "ABI::PerpareTrivialCall()", allowing more detailed information about arguments and return values.

Reviewers: jingham, spyffe

Subscribers: emaste, lldb-commits, ted, ADodds, deepak2427

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

llvm-svn: 242137
2015-07-14 10:56:58 +00:00
Kate Stone ea671fbdff Fixed line wrapping for the "long help" content in LLDB commands. Content is now dynamically wrapped for the column width of the current terminal. Lines that begin with whitespace will be indented identically on subsequent lines to maintain formatting.
Existing commands supplying this type of help content have been reworked to take advantage of the changes.  In addition to formatting changes, content was changes for accuracy and clarity purposes.
    
<rdar://problem/21269977>

llvm-svn: 242122
2015-07-14 05:48:36 +00:00
Chaoren Lin 98d0a4b39a Refactor Unix signals.
Summary:
- Consolidate Unix signals selection in UnixSignals.
- Make Unix signals available from platform.
- Add jSignalsInfo packet to retrieve Unix signals from remote platform.
- Get a copy of the platform signal for each remote process.
- Update SB API for signals.
- Update signal utility in test suite.

Reviewers: ovyalov, clayborg

Subscribers: chaoren, jingham, labath, emaste, tberghammer, lldb-commits

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

llvm-svn: 242101
2015-07-14 01:09:28 +00:00
Pavel Labath 77dc9569c6 Introduce a MainLoop class and switch llgs to use it
Summary:
This is the first part of our effort to make llgs single threaded. Currently, llgs consists of
about three threads and the synchronisation between them is a major source of latency when
debugging linux and android applications.

In order to be able to go single threaded, we must have the ability to listen for events from
multiple sources (primarily, client commands coming over the network and debug events from the
inferior) and perform necessary actions. For this reason I introduce the concept of a MainLoop.
A main loop has the ability to register callback's which will be invoked upon receipt of certain
events. MainLoopPosix has the ability to listen for file descriptors and signals.

For the moment, I have merely made the GDBRemoteCommunicationServerLLGS class use MainLoop
instead of waiting on the network socket directly, but the other threads still remain. In the
followup patches I indend to migrate NativeProcessLinux to this class and remove the remaining
threads.

Reviewers: ovyalov, clayborg, amccarth, zturner, emaste

Subscribers: tberghammer, lldb-commits

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

llvm-svn: 242018
2015-07-13 10:44:55 +00:00
Greg Clayton 1eb778fc2b Unbreak the MacOSX build.
llvm-svn: 241749
2015-07-08 22:21:22 +00:00
Jason Molenda 27467eab81 For the "ios" target add a shell script phase at the end which
removes the LLDB.framework/Resources and LLDB.framework/Swift
directories.  This isn't a deep bundle on ios builds; it is shallow.
    
<rdar://problem/16676101>

llvm-svn: 241540
2015-07-07 03:38:42 +00:00
Tamas Berghammer 3937bc650c Add new bugreport command to lldb
The new command add functionality to print out domain specific
information for reporting a bug. Currently the only supported
domain is stack unwinding (with "bugreport unwind") but adding
new domains is fairly easy.

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

llvm-svn: 241252
2015-07-02 10:03:37 +00:00
Greg Clayton 63cacd7b79 Make sure that SharingPtr.h appears in the LLDB.framework by making it a public header in the LLDB framework target.
This fixes test issues with building lldb/test/api/multithreaded and a few other tests that build against the LLDB.framework in our build directory.

llvm-svn: 240993
2015-06-29 20:42:28 +00:00
Greg Clayton 164a6098a9 Xcode project cleanups.
- Don't have any header files claim to be part of the lldb-core target. If they are part of the lldb-core target then any file can just #include the header file name without the prefix (#include "Foo.h") when the cmake/make/other builds would require a full path (#include "lldb/Core/Foo.h"). This will help make sure the builds succeed on all platforms when changes are made on MacOSX.
- Add the Hexagon dynamic loader to the DynamicLoader plug-in folder so it gets compiled in MacOSX. There was a recent build bot failure that wasn't caught due to this code not being compile in the MacOSX build

llvm-svn: 240714
2015-06-25 22:47:02 +00:00
Greg Clayton b289cba50e Submitting patch from Abhishek for:
http://reviews.llvm.org/D10309

llvm-svn: 240663
2015-06-25 17:50:15 +00:00
Jason Molenda 0c36c27543 xcode project file updates for the movement of the POSIX files into the FreeBSD process subdir.
llvm-svn: 240621
2015-06-25 03:03:47 +00:00
Greg Clayton 9350f0ddac Fix the MacOSX build to include the Mips64 ABI plug-in.
llvm-svn: 240173
2015-06-19 20:08:36 +00:00
Jason Molenda 91ffe0a570 Add a new wart, I mean feature, on to gdb-remote protocol: compression.
For some communication channels, sending large packets can be very 
slow.  In those cases, it may be faster to compress the contents of
the packet on the target device and decompress it on the debug host
system.  For instance, communicating with a device using something
like Bluetooth may be an environment where this tradeoff is a good one.

This patch adds a new field to the response to the "qSupported" packet
(which returns a "qXfer:features:" response) -- SupportedCompressions
and DefaultCompressionMinSize.  These tell you what the remote
stub can support.

lldb, if it wants to enable compression and can handle one of those 
algorithms, it can send a QEnableCompression packet specifying the
algorithm and optionally the minimum packet size to use compression
on.  lldb may have better knowledge about the best tradeoff for
a given communication channel.

I added support to debugserver an lldb to use the zlib APIs
(if -DHAVE_LIBZ=1 is in CFLAGS and -lz is in LDFLAGS) and the
libcompression APIs on Mac OS X 10.11 and later 
(if -DHAVE_LIBCOMPRESSION=1).  libz "zlib-deflate" compression.
libcompression can support deflate, lz4, lzma, and a proprietary
lzfse algorithm.  libcompression has been hand-tuned for Apple
hardware so it should be preferred if available.

debugserver currently only adds the SupportedCompressions when
it is being run on an Apple watch (TARGET_OS_WATCH).  Comment
that #if out from RNBRemote.cpp if you want to enable it to
see how it works.  I haven't tested this on a native system
configuration but surely it will be slower to compress & decompress
the packets in a same-system debug session.

I haven't had a chance to add support for this to 
GDBRemoteCommunciationServer.cpp yet.

<rdar://problem/21090180> 

llvm-svn: 240066
2015-06-18 21:46:06 +00:00
Jason Molenda 651f4e6e1e Add ABISysV_mips.cpp to the xcode project file.
llvm-svn: 240000
2015-06-18 07:32:14 +00:00
Enrico Granata 55d36e2b83 Add a ThreadSafe adapter over llvm::DenseSet
llvm-svn: 239865
2015-06-16 23:20:12 +00:00
Pavel Labath c7c30eb528 Revert "Introduce a TypeSystem interface to support adding non-clang languages."
This seems to break expression evaluation on the linux build.

llvm-svn: 239366
2015-06-08 23:38:06 +00:00
Pavel Labath c33ae024a6 Introduce a TypeSystem interface to support adding non-clang languages.
Reviewers: clayborg

Reviewed By: clayborg

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D8712
Original Author: Ryan Brown <ribrdb@google.com>

llvm-svn: 239360
2015-06-08 22:27:10 +00:00
Greg Clayton 2d7ab874c1 Fix the Xcode build after the recent new demangling files were added.
llvm-svn: 238493
2015-05-28 20:57:55 +00:00
Greg Clayton 424a5dbc73 Added a new API to SBFrame:
lldb::addr_t SBFrame::GetCFA();

This gets the CFA (call frame address) of the frame so it allows us to take an address that is on the stack and figure out which thread it comes from.

Also modified the heap.py module to be able to find out which variable in a frame's stack frame contains an address. This way when ptr_refs finds a match on the stack, it get then report which variable contains the pointer.

llvm-svn: 238393
2015-05-28 03:27:22 +00:00
Tamas Berghammer 0cb78b3b2a Fix xcode project after r238319
llvm-svn: 238321
2015-05-27 14:04:26 +00:00
Enrico Granata e87764f247 Add support for custom commands to set flags on themselves
This works for Python commands defined via a class (implement get_flags on your class) and C++ plugin commands (which can call SBCommand::GetFlags()/SetFlags())

Flags allow features such as not letting the command run if there's no target, or if the process is not stopped, ...
Commands could always check for these things themselves, but having these accessible via flags makes custom commands more consistent with built-in ones

llvm-svn: 238286
2015-05-27 05:04:35 +00:00
Greg Clayton b1ca494b6e Add StructuredData.h to the Xcode project.
llvm-svn: 238278
2015-05-27 03:22:42 +00:00
Greg Clayton d04f0edad9 Added XML to the host layer.
We know have on API we should use for all XML within LLDB in XML.h. This API will be easy back the XML parsing by different libraries in case libxml2 doesn't work on all platforms. It also allows the only place for #ifdef ...XML... to be in XML.h and XML.cpp. The API is designed so it will still compile with or without XML support and there is a static function "bool XMLDocument::XMLEnabled()" that can be called to see if XML is currently supported. All APIs will return errors, false, or nothing when XML isn't enabled.

Converted all locations that used XML over to using the host XML implementation.

Added target.xml support to debugserver. Extended the XML register format to work for LLDB by including extra attributes and elements where needed. This allows the target.xml to replace the qRegisterInfo packets and allows us to fetch all register info in a single packet.

<rdar://problem/21090173>

llvm-svn: 238224
2015-05-26 18:00:51 +00:00
Vince Harron e9efc17974 Change lldb-mi deployment target to use Xcode project global setting
Differential Revision: http://reviews.llvm.org/D9705

llvm-svn: 237598
2015-05-18 19:35:07 +00:00
Greg Clayton 286ea2342d Fix the lldb-mi Xcode project build target to it compiles.
llvm-svn: 237464
2015-05-15 18:38:04 +00:00