Commit Graph

19 Commits

Author SHA1 Message Date
Fangrui Song a8053399cd [ELF][AVR] Add explicit relocation types to getRelExpr 2021-05-12 12:38:27 -07:00
Nico Weber fcf59cc917 fix comment typo to cycle bots 2021-04-23 11:45:49 -04:00
LemonBoy 7a781fb692 [LLD][ELF][AVR] Propagate ELF flags to the linked image
The `e_flags` for a ELF file targeting the AVR ISA contains two fields at the time of writing:
- A 7-bit integer field specifying the ISA revision being targeted
- A 1-bit flag specifying whether the object files being linked are suited for applying the relaxations at link time

The linked ELF file is blessed with the arch revision shared among all the files.
The behaviour in case of mismatch is purposefully different than the one implemented in libbfd: LLD will raise a fatal error while libbfd silently picks a default value of `avr2`.
The relaxation-ready flag is handled as done by libbfd, in order for it to appear in the linked object every source object must be tagged with it.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D99754
2021-04-16 10:40:18 +02:00
Ayke van Laethem 69e60c9dc7
[LLD][ELF][AVR] Implement the missing relocation types
Implements the missing relocation types for AVR target.
The results have been cross-checked with binutils.

Original patch by LemonBoy. Some changes by me.

Differential Revision: https://reviews.llvm.org/D78741
2020-07-12 18:18:54 +02:00
Fangrui Song 07837b8f49 [ELF] Use namespace qualifiers (lld:: or elf::) instead of `namespace lld { namespace elf {`
Similar to D74882. This reverts much code from commit
bd8cfe65f5 (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
2020-05-15 08:49:53 -07:00
Fangrui Song deb5819d62 [ELF] Rename relocateOne() to relocate() and pass `Relocation` to it
Symbol information can be used to improve out-of-range/misalignment diagnostics.
It also helps R_ARM_CALL/R_ARM_THM_CALL which has different behaviors with different symbol types.

There are many (67) relocateOne() call sites used in thunks, {Arm,AArch64}errata, PLT, etc.
Rename them to `relocateNoSym()` to be clearer that there is no symbol information.

Reviewed By: grimar, peter.smith

Differential Revision: https://reviews.llvm.org/D73254
2020-01-25 12:00:18 -08:00
Fangrui Song bd8cfe65f5 [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
2019-10-07 08:31:18 +00:00
Rui Ueyama 3837f4273f [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 05:00:37 +00:00
George Rimar 77b4f0abb8 [LLD][ELF] - Improve diagnostic about unrecognized relocations.
This is a minor improvement inspired by https://bugs.llvm.org/show_bug.cgi?id=38303.

A person reported that he observed message complaining about unsupported R_ARM_V4BX:
error: can't create dynamic relocation R_ARM_V4BX against local symbol in readonly segment; recompile object files with -fPIC

But with -z notext he only saw a relocation number, what is not convenient:
error: ../../gfx/cairo/libpixman/src/pixman-arm-neon-asm-bilinear.o:(.text+0x4F0): unrecognized reloc 40

Also, in the error messages we use relocation but not reloc.

With this patch we start to print one of the following messages:
error: file.o: unrecognized relocation Unknown(999)
error: file.o: unrecognized relocation R_X_KNOWN_BY_LLVM_BUT_UNSUPPORTED_BY_LLD_NAME

There is no way to write a test for that I believe.

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

llvm-svn: 361472
2019-05-23 09:50:18 +00:00
Chandler Carruth 2946cd7010 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
2019-01-19 08:50:56 +00:00
George Rimar 95aae4c59d [ELF] - Do not fail on R_*_NONE relocations when parsing the debug info.
This is https://bugs.llvm.org//show_bug.cgi?id=38919.

Currently, LLD may report "unsupported relocation target while parsing debug info"
when parsing the debug information.

At the same time LLD does that for zeroed R_X86_64_NONE relocations,
which obviously has "invalid" targets.

The nature of R_*_NONE relocation assumes them should be ignored.
This patch teaches LLD to stop reporting the debug information parsing errors for them.

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

llvm-svn: 343078
2018-09-26 08:11:34 +00:00
Rui Ueyama f52496e1e0 Rename SymbolBody -> Symbol
Now that we have only SymbolBody as the symbol class. So, "SymbolBody"
is a bit strange name now. This is a mechanical change generated by

  perl -i -pe s/SymbolBody/Symbol/g $(git grep -l SymbolBody lld/ELF lld/COFF)

nd clang-format-diff.

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

llvm-svn: 317370
2017-11-03 21:21:47 +00:00
Bob Haarman b8a59c8aa5 [lld] unified COFF and ELF error handling on new Common/ErrorHandler
Summary:
The COFF linker and the ELF linker have long had similar but separate
Error.h and Error.cpp files to implement error handling. This change
introduces new error handling code in Common/ErrorHandler.h, changes the
COFF and ELF linkers to use it, and removes the old, separate
implementations.

Reviewers: ruiu

Reviewed By: ruiu

Subscribers: smeenai, jyknight, emaste, sdardis, nemanjai, nhaehnle, mgorny, javed.absar, kbarton, fedor.sergeev, llvm-commits

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

llvm-svn: 316624
2017-10-25 22:28:38 +00:00
Rui Ueyama be85529d2b Remove one parameter from Target::getRelExpr.
A section was passed to getRelExpr just to create an error message.
But if there's an invalid relocation, we would eventually report it
in relocateOne. So we don't have to pass a section to getRelExpr.

llvm-svn: 315552
2017-10-12 03:14:06 +00:00
Rui Ueyama 67533a2cb3 Define RelType to represent relocation types.
We were using uint32_t as the type of relocation kind. It has a
readability issue because what Type really means in `uint32_t Type`
is not obvious. It could be a section type, a symbol type or a
relocation type.

Since we do not do any arithemetic operations on relocation types
(e.g. adding one to R_X86_64_PC32 doesn't make sense), it would be
more natural if they are represented as enums. Unfortunately, that
is not doable because relocation type definitions are spread into
multiple header files.

So I decided to use typedef. This still should be better than the
plain uint32_t because the intended type is now obvious.

llvm-svn: 315525
2017-10-11 22:49:24 +00:00
Rafael Espindola 3bab91332f Fix which file is in an error message.
When reporting an invalid relocation we were blaming the destination
file instead of the file with the relocation.

llvm-svn: 310084
2017-08-04 18:33:16 +00:00
Rui Ueyama e145bc22fd Do not use make<> to allocate TargetInfo. NFC.
llvm-svn: 305577
2017-06-16 20:15:03 +00:00
Rui Ueyama c9fefaac67 Add comments for AVR support.
AVR support is somewhat exotic as generated ELF executables are not
directly consumed but objcopy'ed to write it to on-chip flush memory.
This comment describes it for those why a full-fledged ELF linker is
used to link programs for the 8-bit microcontroller.

llvm-svn: 305567
2017-06-16 17:53:26 +00:00
Rui Ueyama 21c0a9ceeb Split Target.cpp into small files.
Target.cpp contains code for all the targets that LLD supports. It was
simple and easy, but as the number of supported targets increased,
it got messy.

This patch splits the file into per-target files under ELF/arch directory.

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

llvm-svn: 305565
2017-06-16 17:32:43 +00:00