summaryrefslogtreecommitdiffstats
path: root/lldb/unittests/Utility/ArchSpecTest.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Avoid triple corruption while merging core infoMuhammad Omair Javaid2019-12-051-0/+35
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch fixes a bug where when target triple created from elf information is arm-*-linux-eabihf and platform triple is armv8l-*-linux-gnueabihf. Merging both triple results in armv8l--unknown-unknown. This happens because we order a triple update while calling CoreUpdated and CoreUpdated creates a new triple with no vendor or environment information. Making sure we do not update triple and just update to more specific core fixes the issue. Reviewers: labath, jasonmolenda, clayborg Reviewed By: jasonmolenda Subscribers: jankratochvil, kristof.beyls, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70155
* Add arm64_32 support to lldb, an ILP32 codegen Jason Molenda2019-10-161-0/+16
| | | | | | | | | | that runs on arm64 ISA targets, specifically Apple watches. Differential Revision: https://reviews.llvm.org/D68858 llvm-svn: 375032
* Fix bug in ArchSpec::MergeFromGreg Clayton2019-05-081-0/+26
| | | | | | | | | | Previous ArchSpec tests didn't catch this bug since we never tested just the OS being out of date. Fixed the bug and covered this with a test that would catch this. This was found when trying to load a core file where the core file was an ELF file with just the e_machine for architeture and where the ELF header had no OS set in the OSABI field of the e_ident. It wasn't merging the architecture with the target architecture correctly. Differential Revision: https://reviews.llvm.org/D61659 llvm-svn: 360292
* [Utility] Fix ArchSpec.MergeFrom to correctly merge environmentsAlex Langford2019-02-271-16/+40
| | | | | | | | | | | | | | | | Summary: This behavior was originally added in rL252264 (git commit 76a7f365da) in order to be extra careful with handling platforms like watchos and tvos. However, as far as triples go, those two (and others) are treated as OSes and not environments, so that should not really apply here. Additionally, this behavior is incorrect and can lead to incorrect ArchSpecs. Because android is specified as an environment and not an OS, not propogating the environment can lead to modules and targets being misidentified. Differential Revision: https://reviews.llvm.org/D58664 llvm-svn: 354938
* [Utility] Remove Triple{Environment,OS,Vendor}IsUnspecifiedUnknown from ArchSpecAlex Langford2019-02-261-0/+73
| | | | | | | | | | | | | | Summary: These functions should always return the opposite of the `Triple{Environment,OS,Vendor}WasSpecified` functions. Unspecified unknown is the same as unspecified, which is why one set of functions should give us what we want. It's possible to have specified unknown, which is why we can't just rely on checking the enum values of vendor/os/environment. We must also ensure that the names of these are empty and not "unknown". Differential Revision: https://reviews.llvm.org/D58653 llvm-svn: 354933
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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
* Simplify ObjectFile::GetArchitecturePavel Labath2019-01-031-0/+5
| | | | | | | | | | | | | | | | Summary: instead of returning the architecture through by-ref argument and a boolean value indicating success, we can just return the ArchSpec directly. Since the ArchSpec already has an invalid state, it can be used to denote the failure without the additional bool. Reviewers: clayborg, zturner, espindola Subscribers: emaste, arichardson, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D56129 llvm-svn: 350291
* Add another ArchSpec unit test.Adrian Prantl2018-12-061-1/+8
| | | | llvm-svn: 348502
* Add a unit test for ArchSpec matching to document how it behaves (and test it).Adrian Prantl2018-12-061-0/+50
| | | | llvm-svn: 348440
* [ArchSpec] Add a unittest to complement the change in r321856.Davide Italiano2018-01-051-0/+19
| | | | | | <rdar://problem/35778442> llvm-svn: 321879
* Move ArchSpec to the Utility modulePavel Labath2017-11-131-0/+154
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
OpenPOWER on IntegriCloud