summaryrefslogtreecommitdiffstats
path: root/lldb/source/Expression/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
* [Expression] Move IRDynamicChecks to ClangExpressionParserAlex Langford2019-07-121-1/+0
| | | | | | | | | | | | | | | | | | Summary: IRDynamicChecks in its current form is specific to Clang since it deals with the C language family. It is possible that we may want to instrument code generated for other languages, but we can factor in a more general mechanism to do so at a later time. This decouples ObCLanguageRuntime from Expression! Reviewers: compnerd, clayborg, jingham, JDevlieghere Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D64591 llvm-svn: 365853
* [CMake] Correct some dependenciesAlex Langford2019-05-211-0/+1
| | | | | | Symbol doesn't depend on CPlusPlusLanguage, but Expressiond does. llvm-svn: 361216
* [Expression] Remove unused dependencyAlex Langford2019-05-071-1/+0
| | | | | | | | | lldbExpression was linking against lldbPluginExpressionParserClang, and lldbPluginExpressionParserClang was linking against lldbExpression. There's no reason lldbExpression should need anything from lldbPluginExpressionParserClang, so let's remove that dependency. llvm-svn: 360208
* Fix Cmake files for ExpressionSourceCode.cpp -> ClangExpressionSourceCode.cpp.Jim Ingham2019-03-061-1/+0
| | | | llvm-svn: 355561
* Break dependency from Core to ObjectFileJIT.Zachary Turner2018-05-231-0/+1
| | | | | | | | | | | | | | | | | | The only reason this was here was so that Module could have a function called CreateJITModule which created things in a special order. Instead of making this specific to creating JIT modules, I converted this into a template function that can create a module for any type of object file plugin and just forwards arguments through. Since the template is not instantiated in Core, the linker (and header file) dependency moves to the point where it is instantiated, which only happens in Expression. Conceptually, this location also makes more sense for a dependency on ObjectFileJIT. After all, we JIT expressions so it's no surprise that Expression needs to make use of ObjectFileJIT. Differential Revision: https://reviews.llvm.org/D47228 llvm-svn: 333143
* Revert r298776 - Expression: add missing linkage to RuntimeDyld ...Michal Gorny2017-03-301-1/+0
| | | | | | This needs to be addressed within LLVM itself. llvm-svn: 299095
* Expression: add missing linkage to RuntimeDyld componentMichal Gorny2017-03-251-0/+1
| | | | | | | | | | | Add missing linkage from lldbExpression library to LLVMRuntimeDyld. Otherwise the build against shared LLVM libraries fails with: lib64/liblldbExpression.a(IRExecutionUnit.cpp.o):IRExecutionUnit.cpp:function llvm::RTDyldMemoryManager::deregisterEHFrames(unsigned char*, unsigned long, unsigned long): error: undefined reference to 'llvm::RTDyldMemoryManager::deregisterEHFramesInProcess(unsigned char*, unsigned long)' Differential Revision: https://reviews.llvm.org/D31367 llvm-svn: 298776
* [CMake] Add accurate dependency specificationsChris Bieneman2017-01-311-0/+14
| | | | | | | | | | | | | | | | | Summary: This patch adds accurate dependency specifications to the mail LLDB libraries and tools. In all cases except lldb-server, these dependencies are added in addition to existing dependencies (making this low risk), and I performed some code cleanup along the way. For lldb-server I've cleaned up the LLVM dependencies down to just the minimum actually required. This is more than lldb-server actually directly references, and I've left a todo in the code to clean that up. Reviewers: labath, zturner Subscribers: lldb-commits, danalbert, srhines, ki.stfu, mgorny, jgosnell Differential Revision: https://reviews.llvm.org/D29333 llvm-svn: 293686
* [CMake] NFC. Updating CMake dependency specificationsChris Bieneman2016-11-181-4/+7
| | | | | | This patch updates a bunch of places where add_dependencies was being explicitly called to add dependencies on intrinsics_gen to instead use the DEPENDS named parameter. This cleanup is needed for a patch I'm working on to add a dependency debugging mode to the build system. llvm-svn: 287408
* [CMake] LLDB/Expression needs to depend on intrinsics_genChris Bieneman2016-09-291-0/+4
| | | | | | | | IRExecutionUnit.h includes Module.h, which through a long chain of includes eventually includes Attributes.gen. This fixes a build issue reported to lldb-dev by Hal. Thanks Hal! llvm-svn: 282803
* Add a DiagnosticManager replace error streams in the expression parser.Sean Callanan2016-03-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We want to do a better job presenting errors that occur when evaluating expressions. Key to this effort is getting away from a model where all errors are spat out onto a stream where the client has to take or leave all of them. To this end, this patch adds a new class, DiagnosticManager, which contains errors produced by the compiler or by LLDB as an expression is created. The DiagnosticManager can dump itself to a log as well as to a string. Clients will (in the future) be able to filter out the errors they're interested in by ID or present subsets of these errors to the user. This patch is not intended to change the *users* of errors - only to thread DiagnosticManagers to all the places where streams are used. I also attempt to standardize our use of errors a bit, removing trailing newlines and making clients omit 'error:', 'warning:' etc. and instead pass the Severity flag. The patch is testsuite-neutral, with modifications to one part of the MI tests because it relied on "error: error:" being erroneously printed. This patch fixes the MI variable handling and the testcase. <rdar://problem/22864976> llvm-svn: 263859
* Create an expression parser for Go.Ryan Brown2015-11-021-0/+1
| | | | | | | | | | | The Go interpreter doesn't JIT or use LLVM, so this also moves all the JIT related code from UserExpression to a new class LLVMUserExpression. Differential Revision: http://reviews.llvm.org/D13073 Fix merge llvm-svn: 251820
* Added REPL.cpp to the relevant CMakeLists.txtSean Callanan2015-10-191-0/+1
| | | | llvm-svn: 250755
* Moved more Clang-specific parts of the expression parser into the Clang plugin.Sean Callanan2015-09-251-12/+0
| | | | | | | | | 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
* This patch makes Clang-independent base classes for all the expression types ↵Jim Ingham2015-09-151-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [cmake] Remove LLVM_NO_RTTI.Bruce Mitchener2015-09-031-2/+0
| | | | | | | | | | | | | | Summary: This doesn't exist in other LLVM projects any longer and doesn't do anything. Reviewers: chaoren, labath Subscribers: emaste, tberghammer, lldb-commits, danalbert Differential Revision: http://reviews.llvm.org/D12586 llvm-svn: 246749
* Fix cmake build.Bruce Mitchener2015-09-031-1/+1
| | | | llvm-svn: 246746
* Added CMake support so all the Clang modules codeSean Callanan2014-12-051-0/+1
| | | | | | | will at least be built by non-OS X builders. This should head off some build breakage at the pass. llvm-svn: 223437
* Convert to UNIX line endings.Joerg Sonnenberger2013-09-251-23/+23
| | | | llvm-svn: 191367
* cmake build of lldb was complaining about missing files.Sylvestre Ledru2013-04-111-0/+2
| | | | | | | | | Example: CMake Error at cmake/modules/LLVMProcessSources.cmake:89 (message): Found unknown source file /llvm-toolchain-3.3~svn179293.cmake/tools/lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp llvm-svn: 179295
* Update source/Expression/CMakeLists.txt to reflect actual source files.Andy Gibbs2013-03-201-2/+1
| | | | llvm-svn: 177503
* Adding CMake build system to LLDB. Some known issues remain:Daniel Malea2013-02-211-0/+22
- generate-vers.pl has to be called by cmake to generate the version number - parallel builds not yet supported; dependency on clang must be explicitly specified Tested on Linux. - Building on Mac will require code-signing logic to be implemented. - Building on Windows will require OS-detection logic and some selective directory inclusion Thanks to Carlo Kok (who originally prepared these CMakefiles for Windows) and Ben Langmuir who ported them to Linux! llvm-svn: 175795
OpenPOWER on IntegriCloud