|
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, 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 |
|
| #
76e47d48 |
| 26-May-2021 |
Raphael Isemann <[email protected]> |
[lldb][NFC] Use C++ versions of the deprecated C standard library headers
The C headers are deprecated so as requested in D102845, this is replacing them all with their (not deprecated) C++ equivale
[lldb][NFC] Use C++ versions of the deprecated C standard library headers
The C headers are deprecated so as requested in D102845, this is replacing them all with their (not deprecated) C++ equivalent.
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D103084
show more ...
|
|
Revision tags: llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3 |
|
| #
4096ae06 |
| 02-Mar-2021 |
Jan Kratochvil <[email protected]> |
[lldb] Support DWARF-5 DW_FORM_line_strp (used by GCC)
LLDB has been failing on binaries produced by new GCC 11.0 with -gdwarf-5.
Differential Revision: https://reviews.llvm.org/D97721
|
|
Revision tags: 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, 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, llvmorg-10.0.0-rc3 |
|
| #
ddf60ba0 |
| 20-Feb-2020 |
Pavel Labath <[email protected]> |
[lldb/DWARF] Always construct a DWARFDebugInfo object
Change the return value of SymbolFileDWARF::DebugInfo from a pointer to a reference, and remove all null checks.
Previously, we were not constr
[lldb/DWARF] Always construct a DWARFDebugInfo object
Change the return value of SymbolFileDWARF::DebugInfo from a pointer to a reference, and remove all null checks.
Previously, we were not constructing the DebugInfo object when the debug_info section was empty. Now we always construct the object but it will return an empty list of dwarf units (a thing which it already supported).
show more ...
|
| #
00539d8b |
| 17-Feb-2020 |
Pavel Labath <[email protected]> |
[lldb/DWARF] Support the debug_str_offsets section in dwp files
Summary: In dwp files a constant (from the debug_cu_index section) needs to be added to each reference into the debug_str_offsets sect
[lldb/DWARF] Support the debug_str_offsets section in dwp files
Summary: In dwp files a constant (from the debug_cu_index section) needs to be added to each reference into the debug_str_offsets section.
I've tried to implement this to roughly match the llvm flow: I've changed the DWARFormValue to stop resolving the indirect string references directly -- instead, it calls into DWARFUnit, which resolves this for it (similar to how it already resolves indirect range and location list references). I've also done a small refactor of the string offset base computation code in DWARFUnit in order to make it easier to access the debug_cu_index base offset.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74723
show more ...
|
|
Revision tags: llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1 |
|
| #
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 ...
|
|
Revision tags: llvmorg-11-init |
|
| #
a63af915 |
| 08-Jan-2020 |
Alex Langford <[email protected]> |
[lldb] Remove various dead Compare functions
|
|
Revision tags: llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1 |
|
| #
c8b74ee2 |
| 22-Nov-2019 |
Pavel Labath <[email protected]> |
[lldb/DWARF] Add support for DW_AT_loclists_base&DW_FORM_loclistx
Summary: This adds support for DWARF5 location lists which are specified indirectly, via an index into the debug_loclists offset tab
[lldb/DWARF] Add support for DW_AT_loclists_base&DW_FORM_loclistx
Summary: This adds support for DWARF5 location lists which are specified indirectly, via an index into the debug_loclists offset table. This includes parsing the DW_AT_loclists_base attribute which determines the location of this offset table, and support for new form DW_FORM_loclistx which is used in conjuction with DW_AT_location to refer to the location lists in this way.
The code uses the llvm class to parse the offset information, and I've also tried to structure it similarly to how the relevant llvm functionality works.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71268
show more ...
|
| #
1462f5a4 |
| 05-Dec-2019 |
Raphael Isemann <[email protected]> |
[lldb][NFC] Move Address and AddressRange functions out of Stream and let them take raw_ostream
Summary: Yet another step on the long road towards getting rid of lldb's Stream class.
We probably sh
[lldb][NFC] Move Address and AddressRange functions out of Stream and let them take raw_ostream
Summary: Yet another step on the long road towards getting rid of lldb's Stream class.
We probably should just make this some kind of member of Address/AddressRange, but it seems quite often we just push in random integers in there and this is just about getting rid of Stream and not improving arbitrary APIs.
I had to rename another `DumpAddress` function in FormatEntity that is dumping the content of an address to make Clang happy.
Reviewers: labath
Reviewed By: labath
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71052
show more ...
|
|
Revision tags: 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, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3 |
|
| #
6a2eb367 |
| 14-Jun-2019 |
Pavel Labath <[email protected]> |
Have DWARFUnit store a *reference* to SymbolFileDWARF
Previously it was storing a *pointer*, which left open the possibility of this pointer being null. We never made use of that possibility (it doe
Have DWARFUnit store a *reference* to SymbolFileDWARF
Previously it was storing a *pointer*, which left open the possibility of this pointer being null. We never made use of that possibility (it does not make sense), and most of the code was already assuming that. However, there were a couple of null-checks scattered around the code.
This patch replaces the reference with a pointer, making the non-null-ness explicit, and removes the remaining null-checks.
llvm-svn: 363381
show more ...
|
|
Revision tags: llvmorg-8.0.1-rc2 |
|
| #
6aad81cd |
| 24-May-2019 |
Greg Clayton <[email protected]> |
Cleanup fixed form sizes.
The fix form sizes use to have two arrays: one for 4 byte addresses and in for 8 byte addresses. The table had an issue where DW_FORM_flag_present wasn't being represented
Cleanup fixed form sizes.
The fix form sizes use to have two arrays: one for 4 byte addresses and in for 8 byte addresses. The table had an issue where DW_FORM_flag_present wasn't being represented as a fixed size form because its actual size _is_ zero and zero was used to indicate the form isn't fixed in size. Any code that needed to quickly access the DWARF had to get a FixedFormSizes instance using the address byte size.
This fix cleans things up by adding a DWARFFormValue::GetFixedSize() both as a static method and as a member function on DWARFFormValue. It correctly can indicate if a form size is zero. This cleanup is a precursor to a follow up patch where I hope to speed up DWARF parsing.
I verified performance doesn't regress by loading hundreds of DWARF files and setting a breakpoint by file and line and by name in files that do not have DWARF indexes. Performance remained consistent between the two approaches.
Differential Revision: https://reviews.llvm.org/D62416
llvm-svn: 361675
show more ...
|
| #
f750842c |
| 24-May-2019 |
Pavel Labath <[email protected]> |
DWARF: Implement DW_AT_signature lookup for type unit support
Summary: This patch implements the main feature of type units. When completing a type, if we encounter a DW_AT_signature attribute, we u
DWARF: Implement DW_AT_signature lookup for type unit support
Summary: This patch implements the main feature of type units. When completing a type, if we encounter a DW_AT_signature attribute, we use it's value to lookup the complete definition of the type in the relevant type unit.
To enable this lookup, we build up a map of all type units in a symbol file when parsing the units. Then we consult this map when resolving the DW_AT_signature attribute.
I include add a couple of tests which exercise the type lookup feature, including one that ensure we do something reasonable in case we fail to lookup the type.
A lot of the ideas in this patch have been taken from D32167 and D61505.
Reviewers: clayborg, JDevlieghere, aprantl, alexshap
Subscribers: mgrang, lldb-commits
Differential Revision: https://reviews.llvm.org/D62246
llvm-svn: 361603
show more ...
|
| #
248a1305 |
| 23-May-2019 |
Konrad Kleine <[email protected]> |
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary: NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codeba
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary: NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using `nullptr` instread of `0` or `NULL`. See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html for more information.
This is the command I ran and I to fix and format the code base:
``` run-clang-tidy.py \ -header-filter='.*' \ -checks='-*,modernize-use-nullptr' \ -fix ~/dev/llvm-project/lldb/.* \ -format \ -style LLVM \ -p ~/llvm-builds/debug-ninja-gcc ```
NOTE: There were also changes to `llvm/utils/unittest` but I did not include them because I felt that maybe this library shall be updated in isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
show more ...
|
| #
f33f1816 |
| 21-May-2019 |
Pavel Labath <[email protected]> |
DWARF: Port debug_addr over to DWARFContext
llvm-svn: 361232
|
| #
0261b949 |
| 20-May-2019 |
Pavel Labath <[email protected]> |
DWARF: Port most of other sections over to DWARFContext
This moves the sections from SymbolFileDWARF to DWARFContext, where it was trivial to do so. A couple of sections are still left in SymbolFile
DWARF: Port most of other sections over to DWARFContext
This moves the sections from SymbolFileDWARF to DWARFContext, where it was trivial to do so. A couple of sections are still left in SymbolFileDWARF. These will be handled by separate patches.
llvm-svn: 361127
show more ...
|
| #
ff9b4263 |
| 17-May-2019 |
Pavel Labath <[email protected]> |
Make DWARFContext dwo-aware and port debug_info sections over
Summary: The previous attempt and moving section handling over to DWARFContext (D59611) failed because it did not take into account the
Make DWARFContext dwo-aware and port debug_info sections over
Summary: The previous attempt and moving section handling over to DWARFContext (D59611) failed because it did not take into account the dwo sections correctly. All DWARFContexts (even those in SymbolFileDWARFDwo) used the main module for loading the sections, but in the dwo scenario some sections should come from the dwo file.
This patch fixes that by making the DWARFContext aware of whether it a dwo context or a regular one. A dwo context gets two sections lists, and it knows where to look for a particular type of a section. This isn't fully consistent with how the llvm DWARFContext behaves, because that one leaves it up to the user to know whether it should ask for a dwo section or not. However, for the time being, it seems useful to have a single entity which knows how to peice together the debug info in dwo and non-dwo scenarios. The rough roadmap for the future is: - port over the rest of the sections to DWARFContext - find a way to get rid of SymbolFileDWARFDwo/Dwp/DwpDwo. This will likely involve adding the ability for the DWARFContext to spawn dwo sub-contexts, similarly to how it's done in llvm. - get rid of the special handling of the "dwo" contexts by making sure everything knows whether it should ask for the .dwo version of the section or not (similarly to how llvm's DWARFUnits do that)
To demonstrate how the DWARFContext should behave in this new world, I port the debug_info section (which is debug_info.dwo in the dwo file) handling to DWARFContext. The rest of the sections will come in subsequent patches.
Reviewers: aprantl, clayborg, JDevlieghere
Subscribers: zturner, lldb-commits
Differential Revision: https://reviews.llvm.org/D62012
llvm-svn: 361000
show more ...
|
|
Revision tags: llvmorg-8.0.1-rc1 |
|
| #
f4014e11 |
| 16-May-2019 |
Pavel Labath <[email protected]> |
DWARF: Add ability to reference debug info coming from multiple sections
Summary: This patch adds the ability to precisely address debug info in situations when a single file can have more than one
DWARF: Add ability to reference debug info coming from multiple sections
Summary: This patch adds the ability to precisely address debug info in situations when a single file can have more than one debug-info-bearing sections (as is the case with type units in DWARF v4).
The changes here can be classified into roughly three categories: - the code which addresses a debug info by offset gets an additional argument, which specifies the section one should look into. - the DIERef class also gets an additional member variable specifying the section. This way, code dealing with DIERefs can know which section is the object referring to. - the user_id_t encoding steals one bit from the dwarf_id field to store the section. This means the total number of separate object files (apple .o, or normal .dwo) is limited to 2 billion, but that is fine as it's not possible to hit that number without switching to DWARF64 anyway.
This patch is functionally equivalent to (and inspired by) the two patches (D61503 and D61504) by Jan Kratochvil, but there are differences in the implementation: - it uses an enum instead of a bool flag to differentiate the sections - it increases the size of DIERef struct instead of reducing the amount of addressable debug info - it sets up DWARFDebugInfo to store the units in a single vector instead of two. This sets us up for the future in which type units can also live in the debug_info section, and I believe it's cleaner because there's no need for unit index remapping
There are no tests with this patch as this is essentially NFC until we start parsing type units from the debug_types section.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: arphaman, jankratochvil, lldb-commits
Differential Revision: https://reviews.llvm.org/D61908
llvm-svn: 360872
show more ...
|
| #
e8a039d6 |
| 15-May-2019 |
Jan Kratochvil <[email protected]> |
Permit cross-CU references
So far dw_offset_t was global for the whole SymbolFileDWARF but with .debug_types the same dw_offset_t may mean two different things depending on its section (=CU). So ref
Permit cross-CU references
So far dw_offset_t was global for the whole SymbolFileDWARF but with .debug_types the same dw_offset_t may mean two different things depending on its section (=CU). So references now return whole new referenced DWARFDIE instead of just dw_offset_t.
This means that some functions have to now handle 16 bytes instead of 8 bytes but I do not see that anywhere performance critical.
Differential Revision: https://reviews.llvm.org/D61502
llvm-svn: 360795
show more ...
|
| #
041f40e5 |
| 15-May-2019 |
Pavel Labath <[email protected]> |
DWARF: s/CompileUnit/Unit/ in DWARFFormValue
The class has been converted to use DWARFUnit, but a number of uses of the words compile unit remained. This removes all such references Get/SetCompileUn
DWARF: s/CompileUnit/Unit/ in DWARFFormValue
The class has been converted to use DWARFUnit, but a number of uses of the words compile unit remained. This removes all such references Get/SetCompileUnit becomes Get/SetUnit, and m_cu becomes m_unit.
llvm-svn: 360754
show more ...
|
| #
ab0f1807 |
| 27-Mar-2019 |
Pavel Labath <[email protected]> |
Fix a "memset clearing an object of non-trivial type" warning in DWARFFormValue
This is diagnosed by gcc-8. The ValueType struct already has a default constructor which performs zero-initialization,
Fix a "memset clearing an object of non-trivial type" warning in DWARFFormValue
This is diagnosed by gcc-8. The ValueType struct already has a default constructor which performs zero-initialization, so we can just call that instead of using memset.
llvm-svn: 357056
show more ...
|
| #
4c2ef9a0 |
| 22-Mar-2019 |
Pavel Labath <[email protected]> |
Revert "Move the rest of the sections over to DWARFContext."
This reverts commit r356682 because it breaks the DWO flavours of some tests: lldb-Suite :: lang/c/const_variables/TestConstVariables
Revert "Move the rest of the sections over to DWARFContext."
This reverts commit r356682 because it breaks the DWO flavours of some tests: lldb-Suite :: lang/c/const_variables/TestConstVariables.py lldb-Suite :: lang/c/local_variables/TestLocalVariables.py lldb-Suite :: lang/c/vla/TestVLA.py
llvm-svn: 356773
show more ...
|
| #
b4fe87d0 |
| 21-Mar-2019 |
Zachary Turner <[email protected]> |
Move the rest of the sections over to DWARFContext.
This is mostly mechanical, and just moves the remaining non-DWO related sections over to DWARFContext.
Differential Revision: https://reviews.llv
Move the rest of the sections over to DWARFContext.
This is mostly mechanical, and just moves the remaining non-DWO related sections over to DWARFContext.
Differential Revision: https://reviews.llvm.org/D59611
llvm-svn: 356682
show more ...
|
|
Revision tags: llvmorg-8.0.0 |
|
| #
7e44a844 |
| 12-Mar-2019 |
Zachary Turner <[email protected]> |
Remove support for DWARF64.
LLVM doesn't produce DWARF64, and neither does GCC. LLDB's support for DWARF64 is only partial, and if enabled appears to also not work. Finally, it's untested. Removin
Remove support for DWARF64.
LLVM doesn't produce DWARF64, and neither does GCC. LLDB's support for DWARF64 is only partial, and if enabled appears to also not work. Finally, it's untested. Removing this makes merging LLVM and LLDB's DWARF parsing implementations simpler.
Differential Revision: https://reviews.llvm.org/D59235
llvm-svn: 355975
show more ...
|
|
Revision tags: llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4 |
|
| #
d0156256 |
| 07-Mar-2019 |
Ali Tamur <[email protected]> |
[lldb] Fix DW_OP_addrx uses.
Summary: DW_OP_GNU_addr_index has been renamed as DW_OP_addrx in the standard. clang produces DW_OP_addrx tags and with this change lldb starts to process them.
Reviewe
[lldb] Fix DW_OP_addrx uses.
Summary: DW_OP_GNU_addr_index has been renamed as DW_OP_addrx in the standard. clang produces DW_OP_addrx tags and with this change lldb starts to process them.
Reviewers: aprantl, jingham, davide, clayborg, serge-sans-paille
Reviewed By: aprantl
Subscribers: jdoerfert, dblaikie, labath, shafik, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D59004
llvm-svn: 355629
show more ...
|
|
Revision tags: 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 ...
|