[ELF] Clean up headers. NFC

[ELF] Optimize ScriptLexer::getLineNumber by caching the previous line number and offset

getLineNumber() was counting the number of line feeds from the start of
the buffer to the current token. For

[ELF] Optimize ScriptLexer::getLineNumber by caching the previous line number and offset

getLineNumber() was counting the number of line feeds from the start of
the buffer to the current token. For large linker scripts this became a
performance bottleneck. For one 4MB linker script over 4 minutes was
spent in getLineNumber's StringRef::count.

Store the line number from the last token, and only count the additional
line feeds since the last token.

Reviewed By: MaskRay

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

show more ...

[LLD][ELF] - Linkerscript: report location for the "unclosed comment in a linker script" error.

Currently we print "error: unclosed comment in a linker script", which doesn't
provide information abo

[LLD][ELF] - Linkerscript: report location for the "unclosed comment in a linker script" error.

Currently we print "error: unclosed comment in a linker script", which doesn't
provide information about the real error location.

Fixes https://bugs.llvm.org/show_bug.cgi?id=46793.

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

show more ...

[ELF] For relative paths in INPUT() and GROUP(), search the directory of the current linker script before searching other paths

For a relative path in INPUT() or GROUP(), this patch changes the sear

[ELF] For relative paths in INPUT() and GROUP(), search the directory of the current linker script before searching other paths

For a relative path in INPUT() or GROUP(), this patch changes the search order by adding the directory of the current linker script.
The new search order (consistent with GNU ld >= 2.35 regarding the new test `test/ELF/input-relative.s`):

1. the directory of the current linker script (GNU ld from Binutils 2.35 onwards; https://sourceware.org/bugzilla/show_bug.cgi?id=25806)
2. the current working directory
3. library paths (-L)

This behavior makes it convenient to replace a .so or .a with a linker script with additional input. For example, glibc

```
% cat /usr/lib/x86_64-linux-gnu/libm.a
/* GNU ld script
*/
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /usr/lib/x86_64-linux-gnu/libm-2.29.a /usr/lib/x86_64-linux-gnu/libmvec.a )
```

could be simplified as `GROUP(libm-2.29.a libmvec.a)`.

Another example is to make libc++.a a linker script:
```
INPUT(libc++.a.1 libc++abi.a)
```

Note, -l is not affected.

Reviewed By: psmith

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

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

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

[LLD][ELD] - Do not reject INFO output section type when used with a start address.

This is https://bugs.llvm.org/show_bug.cgi?id=38625

LLD accept this:

".stack (INFO) : {",

but not this:

".st

[LLD][ELD] - Do not reject INFO output section type when used with a start address.

This is https://bugs.llvm.org/show_bug.cgi?id=38625

LLD accept this:

".stack (INFO) : {",

but not this:

".stack address_expression (INFO) :"

The patch fixes it.

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

llvm-svn: 340804

show more ...

Move new lld's code to Common subdirectory.

New lld's files are spread under lib subdirectory, and it isn't easy
to find which files are actually maintained. This patch moves maintained
files to Com

Move new lld's code to Common subdirectory.

New lld's files are spread under lib subdirectory, and it isn't easy
to find which files are actually maintained. This patch moves maintained
files to Common subdirectory.

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

llvm-svn: 314719

show more ...

[ELF] - Remove ScriptLexer::Error field and check ErrorCount instead.

D35945 introduces change when there is useless to check Error flag
in few places, but ErrorCount must be checked instead.

But t

[ELF] - Remove ScriptLexer::Error field and check ErrorCount instead.

D35945 introduces change when there is useless to check Error flag
in few places, but ErrorCount must be checked instead.

But then we probably can just check ErrorCount always. That should simplify
things. Patch do that.

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

llvm-svn: 310046

show more ...

Handle ":" as a regular token character in linker scripts.

This is an alternative to https://reviews.llvm.org/D30500 to simplify the
version definition parser and allow ":" in symbol names.

Differe

Handle ":" as a regular token character in linker scripts.

This is an alternative to https://reviews.llvm.org/D30500 to simplify the
version definition parser and allow ":" in symbol names.

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

llvm-svn: 297402

show more ...

Apply different tokenization rules to linker script expressions.

The linker script lexer is context-sensitive. In the regular context,
arithmetic operator characters are regular characters, but in t

Apply different tokenization rules to linker script expressions.

The linker script lexer is context-sensitive. In the regular context,
arithmetic operator characters are regular characters, but in the
expression context, they are independent tokens. This afects how the
lexer tokenizes "3*4", for example. (This kind of expression is real;
the Linux kernel uses it.)

This patch defines function `maybeSplitExpr`. This function splits the
current token into multiple expression tokens if the lexer is in the
expression context.

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

llvm-svn: 295225

show more ...

Rename ScriptParser.{cpp,h} -> ScriptLexer.{cpp,h}.

These files contain a lexer, so the new names are better.
The parser is in LinkerScript.{cpp,h}.

llvm-svn: 295022