Conventionally, an array of SectionPieces is named Pieces.
It is better to follow the convention.

llvm-svn: 315543

llvm-svn: 315537

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

llvm-svn: 315529

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

This patch doesn't change the behavior of the program because it
would eventually return None at end of the function. But it is
better to return None early if we know it will eventually happen.

llvm-svn: 315495

Fixes PR34872.

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

llvm-svn: 315487

llvm-svn: 315442

This is PR34546.

Currently LLD creates output sections even if it has no input sections,
but its command contains an assignment.
Committed code just assigns the same flag that was used in previous
live section.
That does not work sometimes. For example if we have following script:

.ARM.exidx : { *(.ARM.exidx*) }
.foo : { _foo = 0; } }
Then first section has SHF_LINK_ORDER flag. But section foo should not.
That was a reason of crash in OutputSection::finalize(). LLD tried to calculate
Link value, calling front() on empty input sections list.
We should only keep access flags and omit all others when creating such sections.

Patch fixes the crash observed.

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

llvm-svn: 315441

llvm-svn: 315436

llvm-svn: 315434

Usually, a function that does symbol lookup takes symbol name as
its first argument. Also, if a function takes a source location hint,
it is usually the last parameter. So the previous parameter order
was counter-intuitive.

llvm-svn: 315433

Because of r314495, DefinedCommon symbols cannot reach to
getSymbolValue function. When they reach the fucntion, they have
already been converted to DefinedRegular symbols.

llvm-svn: 315432

llvm-svn: 315431

"process" was not a good name because everything can be named it.

llvm-svn: 315430

llvm-svn: 315427

llvm-svn: 315426

We should generally avoid static local variables.

llvm-svn: 315425

llvm-svn: 315424

llvm-svn: 315423

Even though they are called sequentially, they are separate
operations, so it is better to split it.

llvm-svn: 315422

llvm-svn: 315421

llvm-svn: 315420

llvm-svn: 315419

We used CurAddressState to capture a dynamic context just like
we use lambdas to capture static contexts. So, CurAddressState
is used everywhere in LinkerScript.cpp. It is worth a shorter
name.

llvm-svn: 315418

llvm-svn: 315416

llvm-svn: 315415

llvm-svn: 315414

"Commands" was ambiguous because in the linker script, everything is
a command. We used to handle only SECTIONS commands, and at the time,
it might make sense to call them the commands, but it is no longer
the case. We handle not only SECTIONS but also MEMORY, PHDRS, VERSION,
etc., and they are all commands.

llvm-svn: 315409

HasSections is true if there is at least one SECTIONS linker
script command, and it is not directly related to whether we have
section objects or not. So I think the new name is better.

llvm-svn: 315405

llvm-svn: 315404

ScriptConfiguration was a class to contain parsed results of
linker scripts. LinkerScript is a class to interpret it.

That ditinction was needed because we haven't instantiated
LinkerScript early (because, IIRC, LinkerScript class was a
ELFT template function). So, when we parse linker scripts,
we couldn't directly store the result to a LinkerScript instance.

Now, that limitation is gone. We instantiate LinkerScript
at the very beginning of our main function. We can directly
store parse results to a LinkerScript instance.

llvm-svn: 315403

Because addRegular's functionality is tightly coupled with
addSymbol, and the former is called only once, it makes sense
to merge the two functions. This patch also adds comments.

llvm-svn: 315401

I think three ctors are too many for this simple class.

llvm-svn: 315394

llvm-svn: 315393

llvm-svn: 315386

The condition whether a section is alive or not by default
is becoming increasingly complex, so the decision of garbage
collection is spreading over InputSection.h and MarkLive.cpp,
which is not a good state.

This moves the code to MarkLive.cpp, to keep the file the central
place to make decisions about garbage collection.

llvm-svn: 315384

llvm-svn: 315377

We just don't need one with the current setup.

We only error on undefined references that are used by some
relocation.

If we managed to relax all uses of __tls_get_addr, no relocation uses
it and we don't produce an error.

This is less code and fixes the case were we fail to relax. Before we
would produce a broken output, but now we produce an error.

llvm-svn: 315334

When parsing linker scripts, LLD previously started with a '.' value of 0,
regardless of the internal default image base for the target, and regardless of
switches such as --image-base. It seems reasonable to use a different image base
value when using linker scripts and --image-base is specified, since otherwise the
switch has no effect. This change does this, as well as removing unnecessary
initialisation of Dot where it is not used.

The default image base should not be used when processing linker
scripts, because this will change the behaviour for existing linker script users,
and potentially result in invalid output being produced, as a subsequent assignment
to Dot could move the location counter backwards. Instead, we maintain the existing
behaviour of starting from 0 if --image-base is not specified.

Reviewers: ruiu

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

llvm-svn: 315293

When findOrphanPos does the reverse search to find the OutputSection
preceding the orphan's insertion point, look for a live OutputSection
and ignore "dead" OutputSection's. This matches the behaviour of the
forward search performed earlier in this function.

Added test which without the above fix fails as a result of an orphan
executable section being incorrectly placed in a non-executable segment.

Differential Review: https://reviews.llvm.org/D38690

llvm-svn: 315292