[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
2020-01-24 15:23:27 +08:00
|
|
|
//===-- SymbolFileDWARFTests.cpp ------------------------------------------===//
|
2017-01-03 02:20:33 +08:00
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2017-01-03 02:20:33 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "gtest/gtest.h"
|
|
|
|
|
|
|
|
#include "llvm/ADT/STLExtras.h"
|
|
|
|
#include "llvm/DebugInfo/PDB/PDBSymbolData.h"
|
|
|
|
#include "llvm/DebugInfo/PDB/PDBSymbolExe.h"
|
|
|
|
#include "llvm/Support/FileSystem.h"
|
|
|
|
#include "llvm/Support/Path.h"
|
|
|
|
|
2017-06-29 21:02:11 +08:00
|
|
|
#include "Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.h"
|
2019-05-30 23:32:33 +08:00
|
|
|
#include "Plugins/SymbolFile/DWARF/DWARFAbbreviationDeclaration.h"
|
|
|
|
#include "Plugins/SymbolFile/DWARF/DWARFDataExtractor.h"
|
|
|
|
#include "Plugins/SymbolFile/DWARF/DWARFDebugAbbrev.h"
|
2020-03-10 23:05:53 +08:00
|
|
|
#include "Plugins/SymbolFile/DWARF/DWARFDebugArangeSet.h"
|
2020-09-15 03:20:45 +08:00
|
|
|
#include "Plugins/SymbolFile/DWARF/DWARFDebugAranges.h"
|
2017-06-29 21:02:11 +08:00
|
|
|
#include "Plugins/SymbolFile/DWARF/SymbolFileDWARF.h"
|
|
|
|
#include "Plugins/SymbolFile/PDB/SymbolFilePDB.h"
|
[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
2020-01-30 03:59:28 +08:00
|
|
|
#include "Plugins/TypeSystem/Clang/TypeSystemClang.h"
|
2019-12-23 17:38:12 +08:00
|
|
|
#include "TestingSupport/SubsystemRAII.h"
|
2017-11-14 00:16:33 +08:00
|
|
|
#include "TestingSupport/TestUtilities.h"
|
2017-01-03 02:20:33 +08:00
|
|
|
#include "lldb/Core/Address.h"
|
|
|
|
#include "lldb/Core/Module.h"
|
|
|
|
#include "lldb/Core/ModuleSpec.h"
|
2018-11-01 05:49:27 +08:00
|
|
|
#include "lldb/Host/FileSystem.h"
|
2017-01-03 02:20:33 +08:00
|
|
|
#include "lldb/Host/HostInfo.h"
|
|
|
|
#include "lldb/Symbol/CompileUnit.h"
|
|
|
|
#include "lldb/Symbol/LineTable.h"
|
2017-11-14 00:16:33 +08:00
|
|
|
#include "lldb/Utility/ArchSpec.h"
|
2019-05-30 23:32:33 +08:00
|
|
|
#include "lldb/Utility/DataEncoder.h"
|
2017-03-23 02:40:07 +08:00
|
|
|
#include "lldb/Utility/FileSpec.h"
|
2019-05-30 23:32:33 +08:00
|
|
|
#include "lldb/Utility/StreamString.h"
|
2017-01-03 02:20:33 +08:00
|
|
|
|
2019-05-30 23:32:33 +08:00
|
|
|
using namespace lldb;
|
2017-01-03 02:20:33 +08:00
|
|
|
using namespace lldb_private;
|
|
|
|
|
|
|
|
class SymbolFileDWARFTests : public testing::Test {
|
2019-12-23 17:38:12 +08:00
|
|
|
SubsystemRAII<FileSystem, HostInfo, ObjectFilePECOFF, SymbolFileDWARF,
|
[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
2020-01-23 17:04:13 +08:00
|
|
|
TypeSystemClang, SymbolFilePDB>
|
2019-12-23 17:38:12 +08:00
|
|
|
subsystems;
|
|
|
|
|
2017-01-03 02:20:33 +08:00
|
|
|
public:
|
|
|
|
void SetUp() override {
|
2019-12-23 17:38:12 +08:00
|
|
|
m_dwarf_test_exe = GetInputFilePath("test-dwarf.exe");
|
2017-01-03 02:20:33 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
protected:
|
2017-06-29 21:02:11 +08:00
|
|
|
std::string m_dwarf_test_exe;
|
2017-01-03 02:20:33 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
TEST_F(SymbolFileDWARFTests, TestAbilitiesForDWARF) {
|
|
|
|
// Test that when we have Dwarf debug info, SymbolFileDWARF is used.
|
2018-11-02 05:05:36 +08:00
|
|
|
FileSpec fspec(m_dwarf_test_exe);
|
2017-01-03 02:20:33 +08:00
|
|
|
ArchSpec aspec("i686-pc-windows");
|
|
|
|
lldb::ModuleSP module = std::make_shared<Module>(fspec, aspec);
|
|
|
|
|
2019-08-06 17:12:42 +08:00
|
|
|
SymbolFile *symfile = module->GetSymbolFile();
|
|
|
|
ASSERT_NE(nullptr, symfile);
|
2017-01-03 02:20:33 +08:00
|
|
|
EXPECT_EQ(symfile->GetPluginName(), SymbolFileDWARF::GetPluginNameStatic());
|
|
|
|
|
|
|
|
uint32_t expected_abilities = SymbolFile::kAllAbilities;
|
|
|
|
EXPECT_EQ(expected_abilities, symfile->CalculateAbilities());
|
|
|
|
}
|
2019-05-30 23:32:33 +08:00
|
|
|
|
|
|
|
TEST_F(SymbolFileDWARFTests, TestAbbrevOrder1Start1) {
|
|
|
|
// Test that if we have a .debug_abbrev that contains ordered abbreviation
|
|
|
|
// codes that start at 1, that we get O(1) access.
|
2020-09-15 03:20:45 +08:00
|
|
|
|
2019-05-30 23:32:33 +08:00
|
|
|
const auto byte_order = eByteOrderLittle;
|
|
|
|
const uint8_t addr_size = 4;
|
|
|
|
StreamString encoder(Stream::eBinary, addr_size, byte_order);
|
|
|
|
encoder.PutULEB128(1); // Abbrev code 1
|
|
|
|
encoder.PutULEB128(DW_TAG_compile_unit);
|
|
|
|
encoder.PutHex8(DW_CHILDREN_yes);
|
|
|
|
encoder.PutULEB128(DW_AT_name);
|
|
|
|
encoder.PutULEB128(DW_FORM_strp);
|
|
|
|
encoder.PutULEB128(0);
|
|
|
|
encoder.PutULEB128(0);
|
2020-09-15 03:20:45 +08:00
|
|
|
|
2019-05-30 23:32:33 +08:00
|
|
|
encoder.PutULEB128(2); // Abbrev code 2
|
|
|
|
encoder.PutULEB128(DW_TAG_subprogram);
|
|
|
|
encoder.PutHex8(DW_CHILDREN_no);
|
|
|
|
encoder.PutULEB128(DW_AT_name);
|
|
|
|
encoder.PutULEB128(DW_FORM_strp);
|
|
|
|
encoder.PutULEB128(0);
|
|
|
|
encoder.PutULEB128(0);
|
2020-09-15 03:20:45 +08:00
|
|
|
|
2019-05-30 23:32:33 +08:00
|
|
|
encoder.PutULEB128(0); // Abbrev code 0 (termination)
|
2020-09-15 03:20:45 +08:00
|
|
|
|
2019-05-30 23:32:33 +08:00
|
|
|
DWARFDataExtractor data;
|
|
|
|
data.SetData(encoder.GetData(), encoder.GetSize(), byte_order);
|
|
|
|
DWARFAbbreviationDeclarationSet abbrev_set;
|
|
|
|
lldb::offset_t data_offset = 0;
|
|
|
|
llvm::Error error = abbrev_set.extract(data, &data_offset);
|
|
|
|
EXPECT_FALSE(bool(error));
|
|
|
|
// Make sure we have O(1) access to each abbreviation by making sure the
|
|
|
|
// index offset is 1 and not UINT32_MAX
|
2019-06-07 17:43:53 +08:00
|
|
|
EXPECT_EQ(abbrev_set.GetIndexOffset(), 1u);
|
2020-09-15 03:20:45 +08:00
|
|
|
|
2019-05-30 23:32:33 +08:00
|
|
|
auto abbrev1 = abbrev_set.GetAbbreviationDeclaration(1);
|
|
|
|
EXPECT_EQ(abbrev1->Tag(), DW_TAG_compile_unit);
|
|
|
|
EXPECT_TRUE(abbrev1->HasChildren());
|
2019-06-07 17:43:53 +08:00
|
|
|
EXPECT_EQ(abbrev1->NumAttributes(), 1u);
|
2019-05-30 23:32:33 +08:00
|
|
|
auto abbrev2 = abbrev_set.GetAbbreviationDeclaration(2);
|
|
|
|
EXPECT_EQ(abbrev2->Tag(), DW_TAG_subprogram);
|
|
|
|
EXPECT_FALSE(abbrev2->HasChildren());
|
2019-06-07 17:43:53 +08:00
|
|
|
EXPECT_EQ(abbrev2->NumAttributes(), 1u);
|
2019-05-30 23:32:33 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
TEST_F(SymbolFileDWARFTests, TestAbbrevOrder1Start5) {
|
|
|
|
// Test that if we have a .debug_abbrev that contains ordered abbreviation
|
|
|
|
// codes that start at 5, that we get O(1) access.
|
2020-09-15 03:20:45 +08:00
|
|
|
|
2019-05-30 23:32:33 +08:00
|
|
|
const auto byte_order = eByteOrderLittle;
|
|
|
|
const uint8_t addr_size = 4;
|
|
|
|
StreamString encoder(Stream::eBinary, addr_size, byte_order);
|
|
|
|
encoder.PutULEB128(5); // Abbrev code 5
|
|
|
|
encoder.PutULEB128(DW_TAG_compile_unit);
|
|
|
|
encoder.PutHex8(DW_CHILDREN_yes);
|
|
|
|
encoder.PutULEB128(DW_AT_name);
|
|
|
|
encoder.PutULEB128(DW_FORM_strp);
|
|
|
|
encoder.PutULEB128(0);
|
|
|
|
encoder.PutULEB128(0);
|
2020-09-15 03:20:45 +08:00
|
|
|
|
2019-05-30 23:32:33 +08:00
|
|
|
encoder.PutULEB128(6); // Abbrev code 6
|
|
|
|
encoder.PutULEB128(DW_TAG_subprogram);
|
|
|
|
encoder.PutHex8(DW_CHILDREN_no);
|
|
|
|
encoder.PutULEB128(DW_AT_name);
|
|
|
|
encoder.PutULEB128(DW_FORM_strp);
|
|
|
|
encoder.PutULEB128(0);
|
|
|
|
encoder.PutULEB128(0);
|
2020-09-15 03:20:45 +08:00
|
|
|
|
2019-05-30 23:32:33 +08:00
|
|
|
encoder.PutULEB128(0); // Abbrev code 0 (termination)
|
2020-09-15 03:20:45 +08:00
|
|
|
|
2019-05-30 23:32:33 +08:00
|
|
|
DWARFDataExtractor data;
|
|
|
|
data.SetData(encoder.GetData(), encoder.GetSize(), byte_order);
|
|
|
|
DWARFAbbreviationDeclarationSet abbrev_set;
|
|
|
|
lldb::offset_t data_offset = 0;
|
|
|
|
llvm::Error error = abbrev_set.extract(data, &data_offset);
|
|
|
|
EXPECT_FALSE(bool(error));
|
|
|
|
// Make sure we have O(1) access to each abbreviation by making sure the
|
|
|
|
// index offset is 5 and not UINT32_MAX
|
2019-06-07 17:43:53 +08:00
|
|
|
EXPECT_EQ(abbrev_set.GetIndexOffset(), 5u);
|
2020-09-15 03:20:45 +08:00
|
|
|
|
2019-05-30 23:32:33 +08:00
|
|
|
auto abbrev1 = abbrev_set.GetAbbreviationDeclaration(5);
|
|
|
|
EXPECT_EQ(abbrev1->Tag(), DW_TAG_compile_unit);
|
|
|
|
EXPECT_TRUE(abbrev1->HasChildren());
|
2019-06-07 17:43:53 +08:00
|
|
|
EXPECT_EQ(abbrev1->NumAttributes(), 1u);
|
2019-05-30 23:32:33 +08:00
|
|
|
auto abbrev2 = abbrev_set.GetAbbreviationDeclaration(6);
|
|
|
|
EXPECT_EQ(abbrev2->Tag(), DW_TAG_subprogram);
|
|
|
|
EXPECT_FALSE(abbrev2->HasChildren());
|
2019-06-07 17:43:53 +08:00
|
|
|
EXPECT_EQ(abbrev2->NumAttributes(), 1u);
|
2019-05-30 23:32:33 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
TEST_F(SymbolFileDWARFTests, TestAbbrevOutOfOrder) {
|
|
|
|
// Test that if we have a .debug_abbrev that contains unordered abbreviation
|
|
|
|
// codes, that we can access the information correctly.
|
2020-09-15 03:20:45 +08:00
|
|
|
|
2019-05-30 23:32:33 +08:00
|
|
|
const auto byte_order = eByteOrderLittle;
|
|
|
|
const uint8_t addr_size = 4;
|
|
|
|
StreamString encoder(Stream::eBinary, addr_size, byte_order);
|
|
|
|
encoder.PutULEB128(2); // Abbrev code 2
|
|
|
|
encoder.PutULEB128(DW_TAG_compile_unit);
|
|
|
|
encoder.PutHex8(DW_CHILDREN_yes);
|
|
|
|
encoder.PutULEB128(DW_AT_name);
|
|
|
|
encoder.PutULEB128(DW_FORM_strp);
|
|
|
|
encoder.PutULEB128(0);
|
|
|
|
encoder.PutULEB128(0);
|
2020-09-15 03:20:45 +08:00
|
|
|
|
2019-05-30 23:32:33 +08:00
|
|
|
encoder.PutULEB128(1); // Abbrev code 1
|
|
|
|
encoder.PutULEB128(DW_TAG_subprogram);
|
|
|
|
encoder.PutHex8(DW_CHILDREN_no);
|
|
|
|
encoder.PutULEB128(DW_AT_name);
|
|
|
|
encoder.PutULEB128(DW_FORM_strp);
|
|
|
|
encoder.PutULEB128(0);
|
|
|
|
encoder.PutULEB128(0);
|
2020-09-15 03:20:45 +08:00
|
|
|
|
2019-05-30 23:32:33 +08:00
|
|
|
encoder.PutULEB128(0); // Abbrev code 0 (termination)
|
2020-09-15 03:20:45 +08:00
|
|
|
|
2019-05-30 23:32:33 +08:00
|
|
|
DWARFDataExtractor data;
|
|
|
|
data.SetData(encoder.GetData(), encoder.GetSize(), byte_order);
|
|
|
|
DWARFAbbreviationDeclarationSet abbrev_set;
|
|
|
|
lldb::offset_t data_offset = 0;
|
|
|
|
llvm::Error error = abbrev_set.extract(data, &data_offset);
|
|
|
|
EXPECT_FALSE(bool(error));
|
|
|
|
// Make sure we don't have O(1) access to each abbreviation by making sure
|
|
|
|
// the index offset is UINT32_MAX
|
|
|
|
EXPECT_EQ(abbrev_set.GetIndexOffset(), UINT32_MAX);
|
2020-09-15 03:20:45 +08:00
|
|
|
|
2019-05-30 23:32:33 +08:00
|
|
|
auto abbrev1 = abbrev_set.GetAbbreviationDeclaration(2);
|
|
|
|
EXPECT_EQ(abbrev1->Tag(), DW_TAG_compile_unit);
|
|
|
|
EXPECT_TRUE(abbrev1->HasChildren());
|
2019-06-07 17:43:53 +08:00
|
|
|
EXPECT_EQ(abbrev1->NumAttributes(), 1u);
|
2019-05-30 23:32:33 +08:00
|
|
|
auto abbrev2 = abbrev_set.GetAbbreviationDeclaration(1);
|
|
|
|
EXPECT_EQ(abbrev2->Tag(), DW_TAG_subprogram);
|
|
|
|
EXPECT_FALSE(abbrev2->HasChildren());
|
2019-06-07 17:43:53 +08:00
|
|
|
EXPECT_EQ(abbrev2->NumAttributes(), 1u);
|
2019-05-30 23:32:33 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
TEST_F(SymbolFileDWARFTests, TestAbbrevInvalidNULLTag) {
|
|
|
|
// Test that we detect when an abbreviation has a NULL tag and that we get
|
|
|
|
// an error when decoding.
|
2020-09-15 03:20:45 +08:00
|
|
|
|
2019-05-30 23:32:33 +08:00
|
|
|
const auto byte_order = eByteOrderLittle;
|
|
|
|
const uint8_t addr_size = 4;
|
|
|
|
StreamString encoder(Stream::eBinary, addr_size, byte_order);
|
|
|
|
encoder.PutULEB128(1); // Abbrev code 1
|
|
|
|
encoder.PutULEB128(0); // Invalid NULL tag here!
|
|
|
|
encoder.PutHex8(DW_CHILDREN_no);
|
|
|
|
encoder.PutULEB128(0);
|
|
|
|
encoder.PutULEB128(0);
|
2020-09-15 03:20:45 +08:00
|
|
|
|
2019-05-30 23:32:33 +08:00
|
|
|
encoder.PutULEB128(0); // Abbrev code 0 (termination)
|
2020-09-15 03:20:45 +08:00
|
|
|
|
2019-05-30 23:32:33 +08:00
|
|
|
DWARFDataExtractor data;
|
|
|
|
data.SetData(encoder.GetData(), encoder.GetSize(), byte_order);
|
|
|
|
DWARFAbbreviationDeclarationSet abbrev_set;
|
|
|
|
lldb::offset_t data_offset = 0;
|
|
|
|
llvm::Error error = abbrev_set.extract(data, &data_offset);
|
|
|
|
// Verify we get an error
|
|
|
|
EXPECT_TRUE(bool(error));
|
|
|
|
EXPECT_EQ("abbrev decl requires non-null tag.",
|
|
|
|
llvm::toString(std::move(error)));
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_F(SymbolFileDWARFTests, TestAbbrevNullAttrValidForm) {
|
|
|
|
// Test that we detect when an abbreviation has a NULL attribute and a non
|
|
|
|
// NULL form and that we get an error when decoding.
|
2020-09-15 03:20:45 +08:00
|
|
|
|
2019-05-30 23:32:33 +08:00
|
|
|
const auto byte_order = eByteOrderLittle;
|
|
|
|
const uint8_t addr_size = 4;
|
|
|
|
StreamString encoder(Stream::eBinary, addr_size, byte_order);
|
|
|
|
encoder.PutULEB128(1); // Abbrev code 1
|
|
|
|
encoder.PutULEB128(DW_TAG_compile_unit);
|
|
|
|
encoder.PutHex8(DW_CHILDREN_no);
|
|
|
|
encoder.PutULEB128(0); // Invalid NULL DW_AT
|
|
|
|
encoder.PutULEB128(DW_FORM_strp); // With a valid form
|
|
|
|
encoder.PutULEB128(0);
|
|
|
|
encoder.PutULEB128(0);
|
|
|
|
|
|
|
|
encoder.PutULEB128(0); // Abbrev code 0 (termination)
|
2020-09-15 03:20:45 +08:00
|
|
|
|
2019-05-30 23:32:33 +08:00
|
|
|
DWARFDataExtractor data;
|
|
|
|
data.SetData(encoder.GetData(), encoder.GetSize(), byte_order);
|
|
|
|
DWARFAbbreviationDeclarationSet abbrev_set;
|
|
|
|
lldb::offset_t data_offset = 0;
|
|
|
|
llvm::Error error = abbrev_set.extract(data, &data_offset);
|
|
|
|
// Verify we get an error
|
|
|
|
EXPECT_TRUE(bool(error));
|
|
|
|
EXPECT_EQ("malformed abbreviation declaration attribute",
|
|
|
|
llvm::toString(std::move(error)));
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_F(SymbolFileDWARFTests, TestAbbrevValidAttrNullForm) {
|
|
|
|
// Test that we detect when an abbreviation has a valid attribute and a
|
|
|
|
// NULL form and that we get an error when decoding.
|
2020-09-15 03:20:45 +08:00
|
|
|
|
2019-05-30 23:32:33 +08:00
|
|
|
const auto byte_order = eByteOrderLittle;
|
|
|
|
const uint8_t addr_size = 4;
|
|
|
|
StreamString encoder(Stream::eBinary, addr_size, byte_order);
|
|
|
|
encoder.PutULEB128(1); // Abbrev code 1
|
|
|
|
encoder.PutULEB128(DW_TAG_compile_unit);
|
|
|
|
encoder.PutHex8(DW_CHILDREN_no);
|
|
|
|
encoder.PutULEB128(DW_AT_name); // Valid attribute
|
|
|
|
encoder.PutULEB128(0); // NULL form
|
|
|
|
encoder.PutULEB128(0);
|
|
|
|
encoder.PutULEB128(0);
|
2020-09-15 03:20:45 +08:00
|
|
|
|
2019-05-30 23:32:33 +08:00
|
|
|
encoder.PutULEB128(0); // Abbrev code 0 (termination)
|
2020-09-15 03:20:45 +08:00
|
|
|
|
2019-05-30 23:32:33 +08:00
|
|
|
DWARFDataExtractor data;
|
|
|
|
data.SetData(encoder.GetData(), encoder.GetSize(), byte_order);
|
|
|
|
DWARFAbbreviationDeclarationSet abbrev_set;
|
|
|
|
lldb::offset_t data_offset = 0;
|
|
|
|
llvm::Error error = abbrev_set.extract(data, &data_offset);
|
|
|
|
// Verify we get an error
|
|
|
|
EXPECT_TRUE(bool(error));
|
|
|
|
EXPECT_EQ("malformed abbreviation declaration attribute",
|
|
|
|
llvm::toString(std::move(error)));
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_F(SymbolFileDWARFTests, TestAbbrevMissingTerminator) {
|
|
|
|
// Test that we detect when an abbreviation has a valid attribute and a
|
|
|
|
// form, but is missing the NULL attribute and form that terminates an
|
|
|
|
// abbreviation
|
2020-09-15 03:20:45 +08:00
|
|
|
|
2019-05-30 23:32:33 +08:00
|
|
|
const auto byte_order = eByteOrderLittle;
|
|
|
|
const uint8_t addr_size = 4;
|
|
|
|
StreamString encoder(Stream::eBinary, addr_size, byte_order);
|
|
|
|
encoder.PutULEB128(1); // Abbrev code 1
|
|
|
|
encoder.PutULEB128(DW_TAG_compile_unit);
|
|
|
|
encoder.PutHex8(DW_CHILDREN_no);
|
|
|
|
encoder.PutULEB128(DW_AT_name);
|
|
|
|
encoder.PutULEB128(DW_FORM_strp);
|
|
|
|
// Don't add the NULL DW_AT and NULL DW_FORM terminator
|
2020-09-15 03:20:45 +08:00
|
|
|
|
2019-05-30 23:32:33 +08:00
|
|
|
DWARFDataExtractor data;
|
|
|
|
data.SetData(encoder.GetData(), encoder.GetSize(), byte_order);
|
|
|
|
DWARFAbbreviationDeclarationSet abbrev_set;
|
|
|
|
lldb::offset_t data_offset = 0;
|
|
|
|
llvm::Error error = abbrev_set.extract(data, &data_offset);
|
|
|
|
// Verify we get an error
|
|
|
|
EXPECT_TRUE(bool(error));
|
|
|
|
EXPECT_EQ("abbreviation declaration attribute list not terminated with a "
|
|
|
|
"null entry", llvm::toString(std::move(error)));
|
|
|
|
}
|
2020-03-10 23:05:53 +08:00
|
|
|
|
|
|
|
TEST_F(SymbolFileDWARFTests, ParseArangesNonzeroSegmentSize) {
|
|
|
|
// This `.debug_aranges` table header is a valid 32bit big-endian section
|
|
|
|
// according to the DWARFv5 spec:6.2.1, but contains segment selectors which
|
|
|
|
// are not supported by lldb, and should be gracefully rejected
|
|
|
|
const unsigned char binary_data[] = {
|
|
|
|
0, 0, 0, 41, // unit_length (length field not including this field itself)
|
|
|
|
0, 2, // DWARF version number (half)
|
|
|
|
0, 0, 0, 0, // offset into the .debug_info_table (ignored for the purposes
|
|
|
|
// of this test
|
|
|
|
4, // address size
|
|
|
|
1, // segment size
|
|
|
|
// alignment for the first tuple which "begins at an offset that is a
|
|
|
|
// multiple of the size of a single tuple". Tuples are nine bytes in this
|
|
|
|
// example.
|
|
|
|
0, 0, 0, 0, 0, 0,
|
|
|
|
// BEGIN TUPLES
|
|
|
|
1, 0, 0, 0, 4, 0, 0, 0,
|
|
|
|
1, // a 1byte object starting at address 4 in segment 1
|
|
|
|
0, 0, 0, 0, 4, 0, 0, 0,
|
|
|
|
1, // a 1byte object starting at address 4 in segment 0
|
|
|
|
// END TUPLES
|
|
|
|
0, 0, 0, 0, 0, 0, 0, 0, 0 // terminator
|
|
|
|
};
|
|
|
|
DWARFDataExtractor data;
|
|
|
|
data.SetData(static_cast<const void *>(binary_data), sizeof binary_data,
|
|
|
|
lldb::ByteOrder::eByteOrderBig);
|
|
|
|
DWARFDebugArangeSet debug_aranges;
|
|
|
|
offset_t off = 0;
|
|
|
|
llvm::Error error = debug_aranges.extract(data, &off);
|
|
|
|
EXPECT_TRUE(bool(error));
|
|
|
|
EXPECT_EQ("segmented arange entries are not supported",
|
|
|
|
llvm::toString(std::move(error)));
|
2020-03-12 22:30:10 +08:00
|
|
|
EXPECT_EQ(off, 12U); // Parser should read no further than the segment size
|
2020-03-10 23:05:53 +08:00
|
|
|
}
|
2020-09-15 03:20:45 +08:00
|
|
|
|
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
2021-03-26 15:48:49 +08:00
|
|
|
TEST_F(SymbolFileDWARFTests, ParseArangesWithMultipleTerminators) {
|
|
|
|
// This .debug_aranges set has multiple terminator entries which appear in
|
|
|
|
// binaries produced by popular linux compilers and linker combinations. We
|
|
|
|
// must be able to parse all the way through the data for each
|
|
|
|
// DWARFDebugArangeSet. Previously the DWARFDebugArangeSet::extract()
|
|
|
|
// function would stop parsing as soon as we ran into a terminator even
|
|
|
|
// though the length field stated that there was more data that follows. This
|
|
|
|
// would cause the next DWARFDebugArangeSet to be parsed immediately
|
|
|
|
// following the first terminator and it would attempt to decode the
|
|
|
|
// DWARFDebugArangeSet header using the remaining segment + address pairs
|
|
|
|
// from the remaining bytes.
|
|
|
|
unsigned char binary_data[] = {
|
|
|
|
0, 0, 0, 0, // unit_length that will be set correctly after this
|
|
|
|
0, 2, // DWARF version number (uint16_t)
|
|
|
|
0, 0, 0, 0, // CU offset (ignored for the purposes of this test)
|
|
|
|
4, // address size
|
|
|
|
0, // segment size
|
|
|
|
0, 0, 0, 0, // alignment for the first tuple
|
|
|
|
// BEGIN TUPLES
|
|
|
|
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // premature terminator
|
|
|
|
0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x01, 0x00, // [0x1000-0x1100)
|
|
|
|
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // premature terminator
|
|
|
|
0x00, 0x00, 0x20, 0x00, 0x00, 0x00, 0x00, 0x10, // [0x2000-0x2010)
|
|
|
|
// END TUPLES
|
|
|
|
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // terminator
|
|
|
|
};
|
|
|
|
// Set the big endian length correctly.
|
|
|
|
const offset_t binary_data_size = sizeof(binary_data);
|
|
|
|
binary_data[3] = (uint8_t)binary_data_size - 4;
|
|
|
|
DWARFDataExtractor data;
|
|
|
|
data.SetData(static_cast<const void *>(binary_data), sizeof binary_data,
|
|
|
|
lldb::ByteOrder::eByteOrderBig);
|
|
|
|
DWARFDebugArangeSet set;
|
|
|
|
offset_t off = 0;
|
|
|
|
llvm::Error error = set.extract(data, &off);
|
|
|
|
// Multiple terminators are not fatal as they do appear in binaries.
|
|
|
|
EXPECT_FALSE(bool(error));
|
|
|
|
// Parser should read all terminators to the end of the length specified.
|
|
|
|
EXPECT_EQ(off, binary_data_size);
|
|
|
|
ASSERT_EQ(set.NumDescriptors(), 2U);
|
|
|
|
ASSERT_EQ(set.GetDescriptorRef(0).address, (dw_addr_t)0x1000);
|
|
|
|
ASSERT_EQ(set.GetDescriptorRef(0).length, (dw_addr_t)0x100);
|
|
|
|
ASSERT_EQ(set.GetDescriptorRef(1).address, (dw_addr_t)0x2000);
|
|
|
|
ASSERT_EQ(set.GetDescriptorRef(1).length, (dw_addr_t)0x10);
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_F(SymbolFileDWARFTests, ParseArangesIgnoreEmpty) {
|
|
|
|
// This .debug_aranges set has some address ranges which have zero length
|
|
|
|
// and we ensure that these are ignored by our DWARFDebugArangeSet parser
|
|
|
|
// and not included in the descriptors that are returned.
|
|
|
|
unsigned char binary_data[] = {
|
|
|
|
0, 0, 0, 0, // unit_length that will be set correctly after this
|
|
|
|
0, 2, // DWARF version number (uint16_t)
|
|
|
|
0, 0, 0, 0, // CU offset (ignored for the purposes of this test)
|
|
|
|
4, // address size
|
|
|
|
0, // segment size
|
|
|
|
0, 0, 0, 0, // alignment for the first tuple
|
|
|
|
// BEGIN TUPLES
|
|
|
|
0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x01, 0x00, // [0x1000-0x1100)
|
|
|
|
0x00, 0x00, 0x11, 0x00, 0x00, 0x00, 0x00, 0x00, // [0x1100-0x1100)
|
|
|
|
0x00, 0x00, 0x20, 0x00, 0x00, 0x00, 0x00, 0x10, // [0x2000-0x2010)
|
|
|
|
0x00, 0x00, 0x20, 0x10, 0x00, 0x00, 0x00, 0x00, // [0x2010-0x2010)
|
|
|
|
// END TUPLES
|
|
|
|
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // terminator
|
|
|
|
};
|
|
|
|
// Set the big endian length correctly.
|
|
|
|
const offset_t binary_data_size = sizeof(binary_data);
|
|
|
|
binary_data[3] = (uint8_t)binary_data_size - 4;
|
|
|
|
DWARFDataExtractor data;
|
|
|
|
data.SetData(static_cast<const void *>(binary_data), sizeof binary_data,
|
|
|
|
lldb::ByteOrder::eByteOrderBig);
|
|
|
|
DWARFDebugArangeSet set;
|
|
|
|
offset_t off = 0;
|
|
|
|
llvm::Error error = set.extract(data, &off);
|
|
|
|
// Multiple terminators are not fatal as they do appear in binaries.
|
|
|
|
EXPECT_FALSE(bool(error));
|
|
|
|
// Parser should read all terminators to the end of the length specified.
|
|
|
|
// Previously the DWARFDebugArangeSet would stop at the first terminator
|
|
|
|
// entry and leave the offset in the middle of the current
|
|
|
|
// DWARFDebugArangeSet data, and that would cause the next extracted
|
|
|
|
// DWARFDebugArangeSet to fail.
|
|
|
|
EXPECT_EQ(off, binary_data_size);
|
|
|
|
ASSERT_EQ(set.NumDescriptors(), 2U);
|
|
|
|
ASSERT_EQ(set.GetDescriptorRef(0).address, (dw_addr_t)0x1000);
|
|
|
|
ASSERT_EQ(set.GetDescriptorRef(0).length, (dw_addr_t)0x100);
|
|
|
|
ASSERT_EQ(set.GetDescriptorRef(1).address, (dw_addr_t)0x2000);
|
|
|
|
ASSERT_EQ(set.GetDescriptorRef(1).length, (dw_addr_t)0x10);
|
|
|
|
}
|
|
|
|
|
2020-09-15 03:20:45 +08:00
|
|
|
TEST_F(SymbolFileDWARFTests, ParseAranges) {
|
|
|
|
// Test we can successfully parse a DWARFDebugAranges. The initial error
|
|
|
|
// checking code had a bug where it would always return an empty address
|
|
|
|
// ranges for everything in .debug_aranges and no error.
|
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
2021-03-26 15:48:49 +08:00
|
|
|
unsigned char binary_data[] = {
|
|
|
|
0, 0, 0, 0, // unit_length that will be set correctly after this
|
2020-09-15 03:20:45 +08:00
|
|
|
2, 0, // DWARF version number
|
|
|
|
255, 0, 0, 0, // offset into the .debug_info_table
|
|
|
|
8, // address size
|
|
|
|
0, // segment size
|
|
|
|
0, 0, 0, 0, // pad bytes
|
|
|
|
// BEGIN TUPLES
|
|
|
|
// First tuple: [0x1000-0x1100)
|
|
|
|
0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // Address 0x1000
|
|
|
|
0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // Size 0x0100
|
|
|
|
// Second tuple: [0x2000-0x2100)
|
|
|
|
0x00, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // Address 0x2000
|
|
|
|
0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // Size 0x0100
|
|
|
|
// Terminating tuple
|
|
|
|
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // Terminator
|
|
|
|
};
|
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
2021-03-26 15:48:49 +08:00
|
|
|
// Set the little endian length correctly.
|
|
|
|
binary_data[0] = sizeof(binary_data) - 4;
|
2020-09-15 03:20:45 +08:00
|
|
|
DWARFDataExtractor data;
|
|
|
|
data.SetData(static_cast<const void *>(binary_data), sizeof binary_data,
|
|
|
|
lldb::ByteOrder::eByteOrderLittle);
|
|
|
|
DWARFDebugAranges debug_aranges;
|
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
2021-03-26 15:48:49 +08:00
|
|
|
debug_aranges.extract(data);
|
2020-09-15 03:20:45 +08:00
|
|
|
EXPECT_EQ(debug_aranges.GetNumRanges(), 2u);
|
|
|
|
EXPECT_EQ(debug_aranges.FindAddress(0x0fff), DW_INVALID_OFFSET);
|
|
|
|
EXPECT_EQ(debug_aranges.FindAddress(0x1000), 255u);
|
|
|
|
EXPECT_EQ(debug_aranges.FindAddress(0x1100 - 1), 255u);
|
|
|
|
EXPECT_EQ(debug_aranges.FindAddress(0x1100), DW_INVALID_OFFSET);
|
|
|
|
EXPECT_EQ(debug_aranges.FindAddress(0x1fff), DW_INVALID_OFFSET);
|
|
|
|
EXPECT_EQ(debug_aranges.FindAddress(0x2000), 255u);
|
|
|
|
EXPECT_EQ(debug_aranges.FindAddress(0x2100 - 1), 255u);
|
|
|
|
EXPECT_EQ(debug_aranges.FindAddress(0x2100), DW_INVALID_OFFSET);
|
|
|
|
}
|
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
2021-03-26 15:48:49 +08:00
|
|
|
|
|
|
|
TEST_F(SymbolFileDWARFTests, ParseArangesSkipErrors) {
|
|
|
|
// Test we can successfully parse a DWARFDebugAranges that contains some
|
|
|
|
// valid DWARFDebugArangeSet objects and some with errors as long as their
|
|
|
|
// length is set correctly. This helps LLDB ensure that it can parse newer
|
|
|
|
// .debug_aranges version that LLDB currently doesn't support, or ignore
|
|
|
|
// errors in individual DWARFDebugArangeSet objects as long as the length
|
|
|
|
// is set correctly.
|
|
|
|
const unsigned char binary_data[] = {
|
|
|
|
// This DWARFDebugArangeSet is well formed and has a single address range
|
|
|
|
// for [0x1000-0x1100) with a CU offset of 0x00000000.
|
|
|
|
0, 0, 0, 28, // unit_length that will be set correctly after this
|
|
|
|
0, 2, // DWARF version number (uint16_t)
|
|
|
|
0, 0, 0, 0, // CU offset = 0x00000000
|
|
|
|
4, // address size
|
|
|
|
0, // segment size
|
|
|
|
0, 0, 0, 0, // alignment for the first tuple
|
|
|
|
0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x01, 0x00, // [0x1000-0x1100)
|
|
|
|
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // terminator
|
|
|
|
// This DWARFDebugArangeSet has the correct length, but an invalid
|
|
|
|
// version. We need to be able to skip this correctly and ignore it.
|
|
|
|
0, 0, 0, 20, // unit_length that will be set correctly after this
|
|
|
|
0, 44, // invalid DWARF version number (uint16_t)
|
|
|
|
0, 0, 1, 0, // CU offset = 0x00000100
|
|
|
|
4, // address size
|
|
|
|
0, // segment size
|
|
|
|
0, 0, 0, 0, // alignment for the first tuple
|
|
|
|
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // terminator
|
|
|
|
// This DWARFDebugArangeSet is well formed and has a single address range
|
|
|
|
// for [0x2000-0x2100) with a CU offset of 0x00000000.
|
|
|
|
0, 0, 0, 28, // unit_length that will be set correctly after this
|
|
|
|
0, 2, // DWARF version number (uint16_t)
|
|
|
|
0, 0, 2, 0, // CU offset = 0x00000200
|
|
|
|
4, // address size
|
|
|
|
0, // segment size
|
|
|
|
0, 0, 0, 0, // alignment for the first tuple
|
|
|
|
0x00, 0x00, 0x20, 0x00, 0x00, 0x00, 0x01, 0x00, // [0x2000-0x2100)
|
|
|
|
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // terminator
|
|
|
|
};
|
|
|
|
|
|
|
|
DWARFDataExtractor data;
|
|
|
|
data.SetData(static_cast<const void *>(binary_data), sizeof binary_data,
|
|
|
|
lldb::ByteOrder::eByteOrderBig);
|
|
|
|
DWARFDebugAranges debug_aranges;
|
|
|
|
debug_aranges.extract(data);
|
|
|
|
EXPECT_EQ(debug_aranges.GetNumRanges(), 2u);
|
|
|
|
EXPECT_EQ(debug_aranges.FindAddress(0x0fff), DW_INVALID_OFFSET);
|
|
|
|
EXPECT_EQ(debug_aranges.FindAddress(0x1000), 0u);
|
|
|
|
EXPECT_EQ(debug_aranges.FindAddress(0x1100 - 1), 0u);
|
|
|
|
EXPECT_EQ(debug_aranges.FindAddress(0x1100), DW_INVALID_OFFSET);
|
|
|
|
EXPECT_EQ(debug_aranges.FindAddress(0x1fff), DW_INVALID_OFFSET);
|
|
|
|
EXPECT_EQ(debug_aranges.FindAddress(0x2000), 0x200u);
|
|
|
|
EXPECT_EQ(debug_aranges.FindAddress(0x2100 - 1), 0x200u);
|
|
|
|
EXPECT_EQ(debug_aranges.FindAddress(0x2100), DW_INVALID_OFFSET);
|
|
|
|
}
|