summaryrefslogtreecommitdiff
path: root/clang/test/Modules/ModuleDebugInfoDwoId.cpp
AgeCommit message (Collapse)Author
2022-12-12[ZOS] Convert tests to check 'target={{.*}}-zos{{.*}}'Paul Robinson
Also add 'system-zos' as a lit feature and use it where needed. Part of the project to eliminate special handling for triples in lit expressions. Differential Revision: https://reviews.llvm.org/D139444
2022-12-02[lit][AIX] Convert clang tests to use 'target={{.*}}-aix{{.*}}'Paul Robinson
Part of the project to eliminate special handling for triples in lit expressions. Differential Revision: https://reviews.llvm.org/D137437
2021-09-16[AIX][ZOS] Disable LIT tests on AIX and z/OS due to lack of Objective-C supportJake Egan
AIX and z/OS lack Objective-C support, so mark these tests as unsupported for AIX and z/OS. Reviewed By: jsji Differential Revision: https://reviews.llvm.org/D109060
2020-08-24Reland "Correctly emit dwoIDs after ASTFileSignature refactoring (D81347)"Raphael Isemann
The orignal patch with the missing 'REQUIRES: asserts' as there is a debug-only flag used in the test. Original summary: D81347 changes the ASTFileSignature to be an array of 20 uint8_t instead of 5 uint32_t. However, it didn't update the code in ObjectFilePCHContainerOperations that creates the dwoID in the module from the ASTFileSignature (`Buffer->Signature` being the array subclass that is now `std::array<uint8_t, 20>` instead of `std::array<uint32_t, 5>`). ``` uint64_t Signature = [..] (uint64_t)Buffer->Signature[1] << 32 | Buffer->Signature[0] ``` This code works with the old ASTFileSignature (where two uint32_t are enough to fill the uint64_t), but after the patch this only took two bytes from the ASTFileSignature and only partly filled the Signature uint64_t. This caused that the dwoID in the module ref and the dwoID in the actual module no longer match (which in turns causes that LLDB keeps warning about the dwoID's not matching when debugging -gmodules-compiled binaries). This patch just unifies the logic for turning the ASTFileSignature into an uint64_t which makes the dwoID match again (and should prevent issues like that in the future). Reviewed By: aprantl, dang Differential Revision: https://reviews.llvm.org/D84013
2020-08-24Revert "Reland "Correctly emit dwoIDs after ASTFileSignature refactoring ↵Raphael Isemann
(D81347)"" This reverts commit ada2e8ea67393aa8c44fe8e9d46be62df6d1c702. Still breaking on Fuchsia (and also Fedora) with exit code 1, so back to investigating.
2020-08-24Reland "Correctly emit dwoIDs after ASTFileSignature refactoring (D81347)"Raphael Isemann
This relands D84013 but with a test that relies on less shell features to hopefully make the test pass on Fuchsia (where the test from the previous patch version strangely failed with a plain "Exit code 1"). Original summary: D81347 changes the ASTFileSignature to be an array of 20 uint8_t instead of 5 uint32_t. However, it didn't update the code in ObjectFilePCHContainerOperations that creates the dwoID in the module from the ASTFileSignature (`Buffer->Signature` being the array subclass that is now `std::array<uint8_t, 20>` instead of `std::array<uint32_t, 5>`). ``` uint64_t Signature = [..] (uint64_t)Buffer->Signature[1] << 32 | Buffer->Signature[0] ``` This code works with the old ASTFileSignature (where two uint32_t are enough to fill the uint64_t), but after the patch this only took two bytes from the ASTFileSignature and only partly filled the Signature uint64_t. This caused that the dwoID in the module ref and the dwoID in the actual module no longer match (which in turns causes that LLDB keeps warning about the dwoID's not matching when debugging -gmodules-compiled binaries). This patch just unifies the logic for turning the ASTFileSignature into an uint64_t which makes the dwoID match again (and should prevent issues like that in the future). Reviewed By: aprantl, dang Differential Revision: https://reviews.llvm.org/D84013
2020-08-21Revert "Correctly emit dwoIDs after ASTFileSignature refactoring (D81347)"Raphael Isemann
This reverts commit a4c3ed42ba5625af54254584d762ebf96cc06942. The test is curiously failing with a plain exit code 1 on Fuchsia.
2020-08-21Correctly emit dwoIDs after ASTFileSignature refactoring (D81347)Raphael Isemann
D81347 changes the ASTFileSignature to be an array of 20 uint8_t instead of 5 uint32_t. However, it didn't update the code in ObjectFilePCHContainerOperations that creates the dwoID in the module from the ASTFileSignature (`Buffer->Signature` being the array subclass that is now `std::array<uint8_t, 20>` instead of `std::array<uint32_t, 5>`). ``` uint64_t Signature = [..] (uint64_t)Buffer->Signature[1] << 32 | Buffer->Signature[0] ``` This code works with the old ASTFileSignature (where two uint32_t are enough to fill the uint64_t), but after the patch this only took two bytes from the ASTFileSignature and only partly filled the Signature uint64_t. This caused that the dwoID in the module ref and the dwoID in the actual module no longer match (which in turns causes that LLDB keeps warning about the dwoID's not matching when debugging -gmodules-compiled binaries). This patch just unifies the logic for turning the ASTFileSignature into an uint64_t which makes the dwoID match again (and should prevent issues like that in the future). Reviewed By: aprantl, dang Differential Revision: https://reviews.llvm.org/D84013