|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3 |
|
| #
ae869d44 |
| 03-Mar-2022 |
Shafik Yaghmour <[email protected]> |
[LLDB] Remove cases of using namespace llvm:: from header file
We have using namespace llvm::dwarf in dwarf.h header globally. Replacing that with a using namespace within lldb_private::dwarf and mo
[LLDB] Remove cases of using namespace llvm:: from header file
We have using namespace llvm::dwarf in dwarf.h header globally. Replacing that with a using namespace within lldb_private::dwarf and moving to a using namespace lldb_private::dwarf in .cpp files and fully qualified names in the few header files.
Differential Revision: https://reviews.llvm.org/D120836
show more ...
|
|
Revision tags: llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1 |
|
| #
49481b53 |
| 21-Oct-2021 |
Pavel Labath <[email protected]> |
Remove ConstString from Language, LanguageRuntime, SystemRuntime and SymbolFile plugin names
|
| #
a3939e15 |
| 15-Oct-2021 |
Pavel Labath <[email protected]> |
[lldb] Return StringRef from PluginInterface::GetPluginName
There is no reason why this function should be returning a ConstString.
While modifying these files, I also fixed several instances where
[lldb] Return StringRef from PluginInterface::GetPluginName
There is no reason why this function should be returning a ConstString.
While modifying these files, I also fixed several instances where GetPluginName and GetPluginNameStatic were returning different strings.
I am not changing the return type of GetPluginNameStatic in this patch, as that would necessitate additional changes, and this patch is big enough as it is.
Differential Revision: https://reviews.llvm.org/D111877
show more ...
|
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4 |
|
| #
eee30906 |
| 26-Mar-2021 |
Greg Clayton <[email protected]> |
Fix .debug_aranges parsing issues.
When LLVM error handling was introduced to the parsing of the .debug_aranges it would cause major issues if any DWARFDebugArangeSet::extract() calls returned any e
Fix .debug_aranges parsing issues.
When LLVM error handling was introduced to the parsing of the .debug_aranges it would cause major issues if any DWARFDebugArangeSet::extract() calls returned any errors. The code in DWARFDebugInfo::GetCompileUnitAranges() would end up calling DWARFDebugAranges::extract() which would return an error if _any_ DWARFDebugArangeSet had any errors, but it default constructed a DWARFDebugAranges object into DWARFDebugInfo::m_cu_aranges_up and populated it partially, and returned an error prior to finishing much needed functionality in the DWARFDebugInfo::GetCompileUnitAranges() function. Subsequent callers to this function would see that the DWARFDebugInfo::m_cu_aranges_up was actually valid and return this partially populated DWARFDebugAranges reference _and_ it would not be sorted or minimized.
This above bugs would cause an incomplete .debug_aranges parsing, it would skip manually parsing any compile units for ranges, and would not sort the DWARFDebugAranges in m_cu_aranges_up.
This bug would also cause breakpoints set by file and line to fail to set correctly if a symbol context for an address could not be resolved properly, which the incomplete and unsorted DWARFDebugAranges object that DWARFDebugInfo::GetCompileUnitAranges() returned would cause symbol context lookups resolved by address (breakpoint address) to fail to find any DWARF debug info for a given address.
This patch fixes all of the issues that I found: - DWARFDebugInfo::GetCompileUnitAranges() no longer returns a "llvm::Expected<DWARFDebugAranges &>", but just returns a "const DWARFDebugAranges &". Why? Because this code contained a fallback that would parse all of the valid DWARFDebugArangeSet objects, and would check which compile units had valid .debug_aranges set entries, and manually build an address ranges table using DWARFUnit::BuildAddressRangeTable(). If we return an error because any DWARFDebugArangeSet has any errors, then we don't do any of this code. Now we parse all DWARFDebugArangeSet objects that have no errors, if any calls to DWARFDebugArangeSet::extract() return errors, we skip that DWARFDebugArangeSet so that we can use the fallback call to DWARFUnit::BuildAddressRangeTable(). Since DWARFDebugInfo::GetCompileUnitAranges() needs to parse what it can from the .debug_aranges and build address ranges tables for any compile units that don't have any .debug_aranges sets, everything now works as expected. - Fix an issue where a DWARFDebugArangeSet contains multiple terminator entries. The LLVM parser and llvm-dwarfdump properly warn about this because it happens with linux compilers and linkers and was the original cause of the bug I am fixing here. We now correctly warn about this issue if "log enable dwarf info" is enabled, but we continue to parse the DWARFDebugArangeSet correctly so we don't lose data that is contained in the .debug_aranges section. - DWARFDebugAranges::extract() no longer returns a llvm::Error because we need to be able to parse all of the valid DWARFDebugArangeSet objects. It also will correctly skip a DWARFDebugArangeSet object that has errors in the middle of the stream by setting the start offsets of each DWARFDebugArangeSet to be calculated by the previous DWARFDebugArangeSet::extract() calculated offset that uses the header which contains the length of the DWARFDebugArangeSet. This means if do we run into real errors while parsing individual DWARFDebugArangeSet objects, we can continue to parse the rest of the validly encoded DWARFDebugArangeSet objects in the .debug_aranges section. This will allow LLDB to parse DWARF that contains a possibly newer .debug_aranges set format than LLDB currently supports because we will error out for the parsing of the DWARFDebugArangeSet, but be able to skip to the next DWARFDebugArangeSet object using the "DWARFDebugArangeSet.m_header.length" field to calculate the next starting offset.
Tests were added to cover all new functionality.
Differential Revision: https://reviews.llvm.org/D99401
show more ...
|
|
Revision tags: llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3 |
|
| #
79f22b1f |
| 14-Sep-2020 |
Greg Clayton <[email protected]> |
Fix .debug_aranges parsing.
Code was added that used llvm error checking to parse .debug_aranges, but the error check after parsing the DWARFDebugArangesSet was reversed and was causing no error to
Fix .debug_aranges parsing.
Code was added that used llvm error checking to parse .debug_aranges, but the error check after parsing the DWARFDebugArangesSet was reversed and was causing no error to be returned with no valid address ranges being actually used. This meant we always would fall back onto creating out own address ranges by parsing the compile unit's ranges. This was causing problems for cases where the DW_TAG_compile_unit had a single address range by using a DW_AT_low_pc and DW_AT_high_pc attribute pair (not using a DW_AT_ranges attribute), but the .debug_aranges had correct split ranges. In this case we would end up using the single range for the compile unit that encompassed all of the ranges from the .debug_aranges section and would cause address resolving issues in LLDB where address lookups would fail for certain addresses.
Differential Revision: https://reviews.llvm.org/D87626
show more ...
|
|
Revision tags: llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4 |
|
| #
e3fc6b3c |
| 12-Mar-2020 |
Raphael Isemann <[email protected]> |
[lldb][NFC] Fix unsigned/signed comparison warning in SymbolFileDWARFTest.cpp
offset_t is unsigned, so if the RHS is signed we get a warning from clang: warning: comparison of integers of differ
[lldb][NFC] Fix unsigned/signed comparison warning in SymbolFileDWARFTest.cpp
offset_t is unsigned, so if the RHS is signed we get a warning from clang: warning: comparison of integers of different signs: 'const unsigned long long' and 'const int'
show more ...
|
| #
0fa33209 |
| 10-Mar-2020 |
Luke Drummond <[email protected]> |
[lldb] reject `.debug_arange` sections with nonzero segment size
If a producer emits a nonzero segment size, `lldb` will silently read incorrect values and crash, or do something worse later as the
[lldb] reject `.debug_arange` sections with nonzero segment size
If a producer emits a nonzero segment size, `lldb` will silently read incorrect values and crash, or do something worse later as the tuple size is expected to be 2, rather than 3.
Neither LLVM, nor GCC produce segmented aranges, but this dangerous case should still be checked and handled.
Reviewed by: clayborg, labath Differential Revision: https://reviews.llvm.org/D75925 Subscribers: lldb-commits Tags: #lldb
show more ...
|
|
Revision tags: llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1 |
|
| #
8be30215 |
| 29-Jan-2020 |
Alex Langford <[email protected]> |
[lldb] Move clang-based files out of Symbol
Summary: This change represents the move of ClangASTImporter, ClangASTMetadata, ClangExternalASTSourceCallbacks, ClangUtil, CxxModuleHandler, and TypeSyst
[lldb] Move clang-based files out of Symbol
Summary: This change represents the move of ClangASTImporter, ClangASTMetadata, ClangExternalASTSourceCallbacks, ClangUtil, CxxModuleHandler, and TypeSystemClang from lldbSource to lldbPluginExpressionParserClang.h
This explicitly removes knowledge of clang internals from lldbSymbol, moving towards a more generic core implementation of lldb.
Reviewers: JDevlieghere, davide, aprantl, teemperor, clayborg, labath, jingham, shafik
Subscribers: emaste, mgorny, arphaman, jfb, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73661
show more ...
|
| #
80814287 |
| 24-Jan-2020 |
Raphael Isemann <[email protected]> |
[lldb][NFC] Fix all formatting errors in .cpp file headers
Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp ----------------------------------------
[lldb][NFC] Fix all formatting errors in .cpp file headers
Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp -------------------------------------------------===// ``` However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator `-*- C++ -*-` is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files).
This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing `===//` (mostly caused by clang-format breaking the line).
Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73258
show more ...
|
| #
6e3b0cc2 |
| 23-Jan-2020 |
Raphael Isemann <[email protected]> |
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary: This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do (implement the Type
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary: This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do (implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a `clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
show more ...
|
|
Revision tags: llvmorg-11-init |
|
| #
5dca0596 |
| 23-Dec-2019 |
Raphael Isemann <[email protected]> |
[lldb] Add a SubsystemRAII that takes care of calling Initialize and Terminate in the unit tests
Summary: Many of our tests need to initialize certain subsystems/plugins of LLDB such as `FileSystem`
[lldb] Add a SubsystemRAII that takes care of calling Initialize and Terminate in the unit tests
Summary: Many of our tests need to initialize certain subsystems/plugins of LLDB such as `FileSystem` or `HostInfo` by calling their static `Initialize` functions before the test starts and then calling `::Terminate` after the test is done (in reverse order). This adds a lot of error-prone boilerplate code to our testing code.
This patch adds a RAII called SubsystemRAII that ensures that we always call ::Initialize and then call ::Terminate after the test is done (and that the Terminate calls are always in the reverse order of the ::Initialize calls). It also gets rid of all of the boilerplate that we had for these calls.
Per-fixture initialization is still not very nice with this approach as it would require some kind of static unique_ptr that gets manually assigned/reseted from the gtest SetUpTestCase/TearDownTestCase functions. Because of that I changed all per-fixture setup to now do per-test setup which can be done by just having the SubsystemRAII as a member of the test fixture. This change doesn't influence our normal test runtime as LIT anyway runs each test case separately (and the Initialize/Terminate calls are anyway not very expensive). It will however make running all tests in a single executable slightly slower.
Reviewers: labath, JDevlieghere, martong, espindola, shafik
Reviewed By: labath
Subscribers: mgorny, rnkovacs, emaste, MaskRay, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71630
show more ...
|
|
Revision tags: llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2 |
|
| #
465eae36 |
| 06-Aug-2019 |
Pavel Labath <[email protected]> |
SymbolVendor: Remove passthrough methods
After the recent refactorings the SymbolVendor passthrough no longer serve any purpose. This patch removes those methods, and updates all callsites to go to
SymbolVendor: Remove passthrough methods
After the recent refactorings the SymbolVendor passthrough no longer serve any purpose. This patch removes those methods, and updates all callsites to go to the symbol file directly -- in most cases that just means calling GetSymbolFile()->foo() instead of GetSymbolVendor()->foo().
llvm-svn: 368001
show more ...
|
|
Revision tags: llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2 |
|
| #
15fec3a6 |
| 07-Jun-2019 |
Pavel Labath <[email protected]> |
Fix some signed/unsigned comparison warnings
llvm-svn: 362784
|
| #
e6ddde57 |
| 30-May-2019 |
Greg Clayton <[email protected]> |
Fix a regression in DWARF access speed caused by svn revision 356190
The issue was caused by the error checking code that was added. It was incorrectly adding an extra abbreviation when DWARFEnumSta
Fix a regression in DWARF access speed caused by svn revision 356190
The issue was caused by the error checking code that was added. It was incorrectly adding an extra abbreviation when DWARFEnumState::Complete was received since it would push an extra abbreviation onto the list with the abbreviation code of zero. This cause m_idx_offset in each DWARFAbbreviationDeclarationSet to be set to UINT32_MAX. This valid indicates we must linearly search for attributes, not access them in O(1) time. This caused every DWARFDebugInfoEntry that would try to get its DWARFAbbreviationDeclaration from the CU's DWARFAbbreviationDeclarationSet to always linearly search the abbreviation set for a given abbreviation code. Easy to see why this would cause things to be slow.
This regression was caused by: https://reviews.llvm.org/D59370. I asked to ensure there was no regression is parsing or access speed, but that must not have been done. In my test with 40 DWARF files trying to set a breakpoint by function name and in a header file, I see a 8% speed improvement with this fix.
There was no regression in correctness, just very inefficient access.
Added full unit testing for DWARFAbbreviationDeclarationSet parsing to ensure this doesn't regress.
Differential Revision: https://reviews.llvm.org/D62630
llvm-svn: 362105
show more ...
|
| #
5a0e13c4 |
| 29-May-2019 |
Greg Clayton <[email protected]> |
Fixed source header [NFC]
llvm-svn: 361995
|
|
Revision tags: llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
| #
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <[email protected]> |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository.
llvm-svn: 351636
show more ...
|
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1 |
|
| #
8f3be7a3 |
| 01-Nov-2018 |
Jonas Devlieghere <[email protected]> |
[FileSystem] Move path resolution logic out of FileSpec
This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead.
Differential
[FileSystem] Move path resolution logic out of FileSpec
This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead.
Differential revision: https://reviews.llvm.org/D53915
llvm-svn: 345890
show more ...
|
| #
46376966 |
| 31-Oct-2018 |
Jonas Devlieghere <[email protected]> |
[FileSystem] Extend file system and have it use the VFS.
This patch extends the FileSystem class with a bunch of functions that are currently implemented as methods of the FileSpec class. These meth
[FileSystem] Extend file system and have it use the VFS.
This patch extends the FileSystem class with a bunch of functions that are currently implemented as methods of the FileSpec class. These methods will be removed in future commits and replaced by calls to the file system.
The new functions are operated in terms of the virtual file system which was recently moved from clang into LLVM so it could be reused in lldb. Because the VFS is stateful, we turned the FileSystem class into a singleton.
Differential revision: https://reviews.llvm.org/D53532
llvm-svn: 345783
show more ...
|
|
Revision tags: llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2 |
|
| #
5f19b907 |
| 13-Nov-2017 |
Pavel Labath <[email protected]> |
Move ArchSpec to the Utility module
The rationale here is that ArchSpec is used throughout the codebase, including in places which should not depend on the rest of the code in the Core module.
This
Move ArchSpec to the Utility module
The rationale here is that ArchSpec is used throughout the codebase, including in places which should not depend on the rest of the code in the Core module.
This commit touches many files, but most of it is just renaming of #include lines. In a couple of cases, I removed the #include ArchSpec line altogether, as the file was not using it. In one or two places, this necessitated adding other #includes like lldb-private-defines.h.
llvm-svn: 318048
show more ...
|
|
Revision tags: llvmorg-5.0.1-rc1 |
|
| #
a6db4167 |
| 03-Oct-2017 |
Tim Hammerquist <[email protected]> |
cmake + xcode: prevent gtests from using includes from project root
Summary: At present, several gtests in the lldb open source codebase are using #include statements rooted at $(SOURCE_ROOT)/${LLDB
cmake + xcode: prevent gtests from using includes from project root
Summary: At present, several gtests in the lldb open source codebase are using #include statements rooted at $(SOURCE_ROOT)/${LLDB_PROJECT_ROOT}.
This patch cleans up this directory/include structure for both CMake and Xcode build systems.
rdar://problem/33835795
Reviewers: zturner, jingham, beanz
Reviewed By: beanz
Subscribers: emaste, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D36598
llvm-svn: 314849
show more ...
|
|
Revision tags: llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1 |
|
| #
7ed3e22f |
| 29-Jun-2017 |
Pavel Labath <[email protected]> |
[unittests] Add a helper function for getting an input file
Summary: Fetching an input file required about five lines of code, and this was repeated in multiple unit tests, with slight variations. A
[unittests] Add a helper function for getting an input file
Summary: Fetching an input file required about five lines of code, and this was repeated in multiple unit tests, with slight variations. Add a helper function for doing that into the lldbUtilityMocks module (which I rename to lldbUtilityHelpers to commemorate the fact it includes more than mocks)
Reviewers: zturner, eugene
Subscribers: emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D34683
llvm-svn: 306668
show more ...
|
|
Revision tags: llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2, llvmorg-4.0.1-rc1 |
|
| #
5713a05b |
| 22-Mar-2017 |
Zachary Turner <[email protected]> |
Move FileSpec from Host -> Utility.
llvm-svn: 298536
|
|
Revision tags: llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1 |
|
| #
95e26292 |
| 02-Jan-2017 |
Michal Gorny <[email protected]> |
[unittests] Split DWARF tests out of PDB, fix standalone build
Split the PDB tests into DWARF test and actual PDB tests, the latter requiring DIA SDK. Use the new LLVMConfig.cmake LLVM_ENABLE_DIA_SD
[unittests] Split DWARF tests out of PDB, fix standalone build
Split the PDB tests into DWARF test and actual PDB tests, the latter requiring DIA SDK. Use the new LLVMConfig.cmake LLVM_ENABLE_DIA_SDK symbol to enable the PDB tests rather than relying on llvm/Config/config.h private include file that is not available when building standalone.
Differential Revision: https://reviews.llvm.org/D26249
llvm-svn: 290819
show more ...
|