[ELF] Clean up headers. NFC

[ELF] Add ELFFileBase::{elfShdrs,numELFShdrs} to avoid duplicate llvm::object::ELFFile::sections()

This mainly avoid `relsOrRelas` cost in `InputSectionBase::relocate`.
`llvm::object::ELFFile::secti

[ELF] Add ELFFileBase::{elfShdrs,numELFShdrs} to avoid duplicate llvm::object::ELFFile::sections()

This mainly avoid `relsOrRelas` cost in `InputSectionBase::relocate`.
`llvm::object::ELFFile::sections()` has redundant and expensive checks.

show more ...

[ELF] Replace InputBaseSection::{areRelocsRela,firstRelocation,numRelocation} with relSecIdx

For `InputSection` `.foo`, its `InputBaseSection::{areRelocsRela,firstRelocation,numRelocation}` basicall

[ELF] Replace InputBaseSection::{areRelocsRela,firstRelocation,numRelocation} with relSecIdx

For `InputSection` `.foo`, its `InputBaseSection::{areRelocsRela,firstRelocation,numRelocation}` basically
encode the information of `.rel[a].foo`. However, one uint32_t (the relocation section index)
suffices. See the implementation of `relsOrRelas`.

This change decreases sizeof(InputSection) from 184 to 176 on 64-bit Linux.

The maximum resident set size linking a large application (1.2G output) decreases by 0.39%.

Differential Revision: https://reviews.llvm.org/D112513

show more ...

[ELF] Update comments/diagnostics for some long options to use the canonical two-dash form

Rewrite some comments as appropriate.

[lib/Object] - Generalize the RelocationResolver API.

This allows to reuse the RelocationResolver from the code
that doesn't want to deal with `RelocationRef` class.

I am going to use it in llvm-re

[lib/Object] - Generalize the RelocationResolver API.

This allows to reuse the RelocationResolver from the code
that doesn't want to deal with `RelocationRef` class.

I am going to use it in llvm-readobj. See the description
of D91530 for more details.

Differential revision: https://reviews.llvm.org/D91533

show more ...

[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 construct

[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

show more ...

[ELF] Use namespace qualifiers (lld:: or elf::) instead of `namespace lld { namespace elf {`

Similar to D74882. This reverts much code from commit
bd8cfe65f5fee4ad573adc2172359c9552e8cdc0 (D68323) a

[ELF] Use namespace qualifiers (lld:: or elf::) instead of `namespace lld { namespace elf {`

Similar to D74882. This reverts much code from commit
bd8cfe65f5fee4ad573adc2172359c9552e8cdc0 (D68323) and fixes some
problems before D68323.

Sorry for the churn but D68323 was a mistake. Namespace qualifiers avoid
bugs where the definition does not match the declaration from the
header. See
https://llvm.org/docs/CodingStandards.html#use-namespace-qualifiers-to-implement-previously-declared-functions (D74515)

Differential Revision: https://reviews.llvm.org/D79982

show more ...

[ELF] --gdb-index: support .debug_loclists

--gdb-index currently crashes when reading a translation unit with
DWARF v5 .debug_loclists . Call stack:

```
SyntheticSections.cpp GdbIndexSection::creat

[ELF] --gdb-index: support .debug_loclists

--gdb-index currently crashes when reading a translation unit with
DWARF v5 .debug_loclists . Call stack:

```
SyntheticSections.cpp GdbIndexSection::create
SyntheticSections.cpp readAddressAreas
DWARFUnit.cpp DWARFUnit::tryExtractDIEsIfNeeded
DWARFListTable.cpp DWARFListTableHeader::extract
...
DWARFDataExtractor.cpp DWARFDataExtractor::getRelocatedValue
lld/ELF/DWARF.cpp LLDDwarfObj<ELFT>::find (sec.sec is nullptr)
...

```

This patch adds support for .debug_loclists to make `DWARFUnit::tryExtractDIEsIfNeeded` happy.
Building --gdb-index does not need .debug_loclists

Reviewed By: dblaikie, grimar

Differential Revision: https://reviews.llvm.org/D79061

show more ...

[LLD][NFC] Remove getOffsetInFile() workaround.

Summary:
LLD has workaround for the times when SectionIndex was not passed properly:

LT->getFileLineInfoForAddress(
S->getOffsetInFile() + Offs

[LLD][NFC] Remove getOffsetInFile() workaround.

Summary:
LLD has workaround for the times when SectionIndex was not passed properly:

LT->getFileLineInfoForAddress(
S->getOffsetInFile() + Offset, nullptr,
DILineInfoSpecifier::FileLineInfoKind::AbsoluteFilePath, Info));

S->getOffsetInFile() was added to differentiate offsets between
various sections. Now SectionIndex is properly specified.
Thus it is not necessary to use getOffsetInFile() workaround.
See https://reviews.llvm.org/D58194, https://reviews.llvm.org/D58357.

This patch removes getOffsetInFile() workaround.

Reviewers: ruiu, grimar, MaskRay, espindola

Reviewed By: grimar, MaskRay

Subscribers: emaste, arichardson, llvm-commits

Tags: #llvm, #lld

Differential Revision: https://reviews.llvm.org/D75636

show more ...

[ELF] Wrap things in `namespace lld { namespace elf {`, NFC

This makes it clear `ELF/**/*.cpp` files define things in the `lld::elf`
namespace and simplifies `elf::foo` to `foo`.

Reviewed By: atana

[ELF] Wrap things in `namespace lld { namespace elf {`, NFC

This makes it clear `ELF/**/*.cpp` files define things in the `lld::elf`
namespace and simplifies `elf::foo` to `foo`.

Reviewed By: atanasyan, grimar, ruiu

Differential Revision: https://reviews.llvm.org/D68323

llvm-svn: 373885

show more ...

gdb-index: Wire up str_offsets section to avoid incorrect error message about offsets_base

There's still a need for a deeper fix to the way libDebugInfoDWARF error
messages are propagated up to lld

gdb-index: Wire up str_offsets section to avoid incorrect error message about offsets_base

There's still a need for a deeper fix to the way libDebugInfoDWARF error
messages are propagated up to lld - if lld had exited non-zero on this
error message we would've found the issue sooner.

llvm-svn: 368229

show more ...

API update for change to LLVM's lib/DebugInfo/DWARF

llvm-svn: 368190

[DWARF][RISCV] Add support for RISC-V relocations needed for debug info

When code relaxation is enabled many RISC-V fixups are not resolved but
instead relocations are emitted. This happens even for

[DWARF][RISCV] Add support for RISC-V relocations needed for debug info

When code relaxation is enabled many RISC-V fixups are not resolved but
instead relocations are emitted. This happens even for DWARF debug
sections. Therefore, to properly support the parsing of DWARF debug info
we need to be able to resolve RISC-V relocations. This patch adds:

* Support for RISC-V relocations in RelocationResolver
* DWARF support for two relocations per object file offset
* DWARF changes to support relocations in more DIE fields

The two relocations per offset change is needed because some RISC-V
relocations (used for label differences) come in pairs.

Relocations can also be emitted for DWARF fields where relocations were
not yet evaluated. Adding relocation support for some of these fields is
essencial. On the other hand, LLVM currently emits RISC-V relocations
for fixups that could be safely evaluated, since they can never be
affected by code relaxations. This patch also adds relocation support
for the fields affected by those extraneous relocations (the DWARF unit
entry Length, and the DWARF debug line entry TotalLength and
PrologueLength), for testing purposes.

Differential Revision: https://reviews.llvm.org/D62062
Patch by Luís Marques.

llvm-svn: 366402

show more ...

[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

[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

show more ...

Avoid identifiers that are different only in case. NFC.

Some variables in lld have the same name as functions ignoring case.
This patch gives them different names, so that my next patch is easier
to

Avoid identifiers that are different only in case. NFC.

Some variables in lld have the same name as functions ignoring case.
This patch gives them different names, so that my next patch is easier
to read.

llvm-svn: 365003

show more ...

Cleanup: llvm::bsearch -> llvm::partition_point after r364719

llvm-svn: 364720

Reland D61583 [ELF] Error on relocations to STT_SECTION symbols if the sections were discarded

This restores r361830 "[ELF] Error on relocations to STT_SECTION symbols if the sections were discarded

Reland D61583 [ELF] Error on relocations to STT_SECTION symbols if the sections were discarded

This restores r361830 "[ELF] Error on relocations to STT_SECTION symbols if the sections were discarded"
and dependent commits (r362218, r362497) which were reverted by r364321, with a fix of a --gdb-index issue.

.rela.debug_ranges contains relocations of range list entries:

// start address of a range list entry
// old: 0; after r361830: 0
00000000000033a0 R_X86_64_64 .text._ZN2v88internal7Isolate7factoryEv + 0
// end address of a range list entry
// old: 0xe; after r361830: 0
00000000000033a8 R_X86_64_64 .text._ZN2v88internal7Isolate7factoryEv + e

If both start and end addresses of a range list entry resolve to 0,
DWARFDebugRangeList::isEndOfListEntry() will return true, then the
.debug_range decoding loop will terminate prematurely:

while (true) {
decode StartAddress
decode EndAddress
if (Entry.isEndOfListEntry()) // prematurely
break;
Entries.push_back(Entry);
}

In lld/ELF/SyntheticSections.cpp, readAddressAreas() will read
incomplete address ranges and the resulting .gdb_index will be
incomplete. For files that gdb hasn't loaded their debug info, gdb uses
.gdb_index to map addresses to CUs. The absent entries make gdb fail to
symbolize some addresses.

To address this issue, we simply allow relocations to undefined symbols
in DWARF.cpp:findAux() and let RelocationResolver resolve them.

This patch should fix:

[1] http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190603/659848.html
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=978067

llvm-svn: 364391

show more ...

Revert r362743 "Revert "Revert "Reland D61583 [ELF] Error on relocations to STT_SECTION symbols if the sections were discarded"""

(In effect, reverting "[ELF] Error on relocations to STT_SECTION sym

Revert r362743 "Revert "Revert "Reland D61583 [ELF] Error on relocations to STT_SECTION symbols if the sections were discarded"""

(In effect, reverting "[ELF] Error on relocations to STT_SECTION symbols if the sections were discarded".)

It caused debug info problems in LibreOffice [1] and Chromium/V8 [2].
Reverting until those can be fixed.

It also reverts r362497 "STT_SECTION symbol should be defined" on .eh_frame, .debug*, .zdebug* and .gcc_except_table"
which was landed as a follow-up to the above.

> With -r or --emit-relocs, we warn `STT_SECTION symbol should be defined`
> on relocations to discarded section symbol. This was added as an error
> in rLLD319404, but was not so effective before D61583 (it turned the
> error to a warning).
>
> Relocations from .eh_frame .debug* .zdebug* .gcc_except_table to
> discarded .text are very common and somewhat expected. Don't warn/error
> on them. As a reference, ld.bfd has a similar logic in
> _bfd_elf_default_action_discarded() to allow these cases.
>
> Delete invalid-undef-section-symbol.test because what it intended to
> check is now covered by the updated comdat-discarded-reloc.s
>
> Delete relocatable-eh-frame.s because we allow relocations from
> .eh_frame as a special case now.

And finally it reverts r362218 "[ELF] Replace a dead test in getSymVA() with assert()"
as that also depended on the main change reverted here.

> Symbols relative to discarded comdat sections are Undefined instead of
> Defined now (after D59649 and D61583). The `== &InputSection::Discarded`
> test becomes dead. I cannot find a test related to this behavior.

[1] http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190603/659848.html
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=978067

llvm-svn: 364321

show more ...

Revert "Revert "Reland D61583 [ELF] Error on relocations to STT_SECTION symbols if the sections were discarded""

This reverts commit 729111cf1824159bb4dd331cab8a829eab30313f.

Reverting the previous

Revert "Revert "Reland D61583 [ELF] Error on relocations to STT_SECTION symbols if the sections were discarded""

This reverts commit 729111cf1824159bb4dd331cab8a829eab30313f.

Reverting the previous commit breaks other LLD buildbots.

llvm-svn: 362743

show more ...

Revert "Reland D61583 [ELF] Error on relocations to STT_SECTION symbols if the sections were discarded"

This reverts commit 5d3b3188f722456a6470c7effcacf17656406429.

Breaks the PowerPC multi-stage

Revert "Reland D61583 [ELF] Error on relocations to STT_SECTION symbols if the sections were discarded"

This reverts commit 5d3b3188f722456a6470c7effcacf17656406429.

Breaks the PowerPC multi-stage buildbot.

llvm-svn: 362739

show more ...

Reland D61583 [ELF] Error on relocations to STT_SECTION symbols if the sections were discarded

This is implemented by creating Undefined (instead of Defined) for such
local STT_SECTION symbols. It a

Reland D61583 [ELF] Error on relocations to STT_SECTION symbols if the sections were discarded

This is implemented by creating Undefined (instead of Defined) for such
local STT_SECTION symbols. It allows us to catch errors when there are
relocations to such discarded sections (e.g. in PR41693, ld.bfd and gold
error but we don't). Updated comdat-discarded-error.s checks we emit
friendly error message.

For relocatable-eh-frame.s, ld.lld -r a.o a.o will now error
"STT_SECTION symbol should be defined" because the section .eh_frame
refers to is now an Undefined instead of a Defined.
So I have to change `error()` to `warn()` to retain the output.

rLLD361144 inadvertently enabled the error for --gdb-index
(in LLDDwarfObj<ELFT>::findAux()).

Relocations from .debug_info (not in comdat) to .text.* (in comdat) for
DW_AT_low_pc are common. If an .text.* was discarded, rLLD361144 would error,
which was unexpected. (Note, if we don't error as this patch does,
InputSection::relocateNonAlloc() will resolve such relocations).

llvm-svn: 361830

show more ...

[ELF] Use llvm::bsearch. NFC

Differential Revision: https://reviews.llvm.org/D60813

llvm-svn: 358565

ELF: De-template ELFFileBase. NFCI.

Differential Revision: https://reviews.llvm.org/D60304

llvm-svn: 357806

[DWARF] Refactor RelocVisitor and fix computation of SHT_RELA-typed relocation entries

Summary: This is the lld-side change of D57939

Reviewers: echristo, dblaikie, ruiu, espindola

Reviewed By: ec

[DWARF] Refactor RelocVisitor and fix computation of SHT_RELA-typed relocation entries

Summary: This is the lld-side change of D57939

Reviewers: echristo, dblaikie, ruiu, espindola

Reviewed By: echristo, ruiu

Subscribers: jdoerfert, emaste, arichardson, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D57940

llvm-svn: 356730

show more ...

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 ...