llvm-project/lld/ELF/DWARF.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

107 lines
3.0 KiB
C
Raw Normal View History

//===- DWARF.h -----------------------------------------------*- C++ -*-===//
//
// 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
//
//===-------------------------------------------------------------------===//
#ifndef LLD_ELF_DWARF_H
#define LLD_ELF_DWARF_H
#include "InputFiles.h"
#include "llvm/ADT/STLExtras.h"
#include "llvm/DebugInfo/DWARF/DWARFContext.h"
#include "llvm/Object/ELF.h"
namespace lld {
namespace elf {
class InputSection;
struct LLDDWARFSection final : public llvm::DWARFSection {
InputSectionBase *sec = nullptr;
};
template <class ELFT> class LLDDwarfObj final : public llvm::DWARFObject {
public:
explicit LLDDwarfObj(ObjFile<ELFT> *obj);
2018-09-15 07:51:17 +08:00
void forEachInfoSections(
llvm::function_ref<void(const llvm::DWARFSection &)> f) const override {
f(infoSection);
}
2018-09-15 07:51:17 +08:00
[ELF] --gdb-index: skip SHF_GROUP .debug_info -gdwarf-5 -fdebug-types-section may produce multiple .debug_info sections. All except one are type units (.debug_types before DWARF v5). When constructing .gdb_index, we should ignore these type units. We use a simple heuristic: the compile unit does not have the SHF_GROUP flag. (This needs to be revisited if people place compile unit .debug_info in COMDAT groups.) This issue manifests as a data race: because an object file may have multiple .debug_info sections, we may concurrently construct `LLDDwarfObj` for the same file in multiple threads. The threads may access `InputSectionBase::data()` concurrently on the same input section. `InputSectionBase::data()` does a lazy uncompress() and rewrites the member variable `rawData`. A thread running zlib `inflate()` (transitively called by uncompress()) on a buffer with `rawData` tampered by another thread may fail with `uncompress failed: zlib error: Z_DATA_ERROR`. Even if no data race occurred in an optimistic run, if there are N .debug_info, one CU entry and its address ranges will be replicated N times. The result .gdb_index can be much larger than a correct one. The new test gdb-index-dwarf5-type-unit.s actually has two compile units. This cannot be produced with regular approaches (it can be produced with -r --unique). This is used to demonstrate that the .gdb_index construction code only considers the last non-SHF_GROUP .debug_info Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D85579
2020-08-13 11:50:59 +08:00
InputSection *getInfoSection() const {
return cast<InputSection>(infoSection.sec);
}
const llvm::DWARFSection &getLoclistsSection() const override {
return loclistsSection;
}
const llvm::DWARFSection &getRangesSection() const override {
return rangesSection;
}
2018-09-15 07:51:17 +08:00
const llvm::DWARFSection &getRnglistsSection() const override {
return rnglistsSection;
}
const llvm::DWARFSection &getStrOffsetsSection() const override {
return strOffsetsSection;
}
const llvm::DWARFSection &getLineSection() const override {
return lineSection;
}
2018-09-15 07:51:17 +08:00
const llvm::DWARFSection &getAddrSection() const override {
return addrSection;
}
const LLDDWARFSection &getGnuPubnamesSection() const override {
return gnuPubnamesSection;
}
2018-09-15 07:51:17 +08:00
const LLDDWARFSection &getGnuPubtypesSection() const override {
return gnuPubtypesSection;
}
2018-09-15 07:51:17 +08:00
StringRef getFileName() const override { return ""; }
StringRef getAbbrevSection() const override { return abbrevSection; }
StringRef getStrSection() const override { return strSection; }
StringRef getLineStrSection() const override { return lineStrSection; }
bool isLittleEndian() const override {
return ELFT::TargetEndianness == llvm::support::little;
}
2018-09-15 07:51:17 +08:00
llvm::Optional<llvm::RelocAddrEntry> find(const llvm::DWARFSection &sec,
uint64_t pos) const override;
2018-09-15 07:51:17 +08:00
private:
template <class RelTy>
llvm::Optional<llvm::RelocAddrEntry> findAux(const InputSectionBase &sec,
uint64_t pos,
ArrayRef<RelTy> rels) const;
[Coding style change] Rename variables so that they start with a lowercase letter This patch is mechanically generated by clang-llvm-rename tool that I wrote using Clang Refactoring Engine just for creating this patch. You can see the source code of the tool at https://reviews.llvm.org/D64123. There's no manual post-processing; you can generate the same patch by re-running the tool against lld's code base. Here is the main discussion thread to change the LLVM coding style: https://lists.llvm.org/pipermail/llvm-dev/2019-February/130083.html In the discussion thread, I proposed we use lld as a testbed for variable naming scheme change, and this patch does that. I chose to rename variables so that they are in camelCase, just because that is a minimal change to make variables to start with a lowercase letter. Note to downstream patch maintainers: if you are maintaining a downstream lld repo, just rebasing ahead of this commit would cause massive merge conflicts because this patch essentially changes every line in the lld subdirectory. But there's a remedy. clang-llvm-rename tool is a batch tool, so you can rename variables in your downstream repo with the tool. Given that, here is how to rebase your repo to a commit after the mass renaming: 1. rebase to the commit just before the mass variable renaming, 2. apply the tool to your downstream repo to mass-rename variables locally, and 3. rebase again to the head. Most changes made by the tool should be identical for a downstream repo and for the head, so at the step 3, almost all changes should be merged and disappear. I'd expect that there would be some lines that you need to merge by hand, but that shouldn't be too many. Differential Revision: https://reviews.llvm.org/D64121 llvm-svn: 365595
2019-07-10 13:00:37 +08:00
LLDDWARFSection gnuPubnamesSection;
LLDDWARFSection gnuPubtypesSection;
2018-09-15 07:51:17 +08:00
LLDDWARFSection infoSection;
LLDDWARFSection loclistsSection;
LLDDWARFSection rangesSection;
LLDDWARFSection rnglistsSection;
LLDDWARFSection strOffsetsSection;
2018-09-15 07:51:17 +08:00
LLDDWARFSection lineSection;
LLDDWARFSection addrSection;
2018-09-15 07:51:17 +08:00
StringRef abbrevSection;
StringRef strSection;
StringRef lineStrSection;
};
} // namespace elf
} // namespace lld
#endif