This patch causes us to use pruneCache() to prune the ThinLTO cache after
completing LTO. A new flag --thinlto-cache-policy allows users to configure
the policy.

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

llvm-svn: 298036

After the call to sys::fs::exists succeeds, indicating a cache hit, we call
AddFile and the client will open the file using the supplied path. If the
client is using cache pruning, there is a potential race between the pruner
and the client. To avoid this, change the caching API so that it provides
a MemoryBuffer to the client, and have clients use that MemoryBuffer where
possible.

This scheme won't work with the gold plugin because the plugin API expects a
file path. So we have the gold plugin use the buffer identifier as a path and
live with the race for now. (Note that the gold plugin isn't actually affected
by the problem at the moment because it doesn't support cache pruning.)

This effectively reverts r279883 modulo the change to use the existing path
in the gold plugin.

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

llvm-svn: 298020

This reverts commit r297850 because this change was made
based on a miscommunication.

llvm-svn: 298001

Addresses post commit review comment.

llvm-svn: 297953

That opens road to detemplate PltSection<ELFT>,
what allows then to detemplate all methods of SymbolBody.

llvm-svn: 297950

Excessive typename keyword.

llvm-svn: 297949

That allows to detemplate getGotPltOffset/getGotPltVA
methods of SymbolBody and also will help to detemplate
DynamicReloc itself later.

llvm-svn: 297946

llvm-svn: 297944

llvm-svn: 297943

llvm-svn: 297942

llvm-svn: 297941

llvm-svn: 297939

llvm-svn: 297938

llvm-svn: 297937

I suppose it is the reason of BB fail:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-lld/builds/921

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

llvm-svn: 297933

Suggested by Rui Ueyama,
also groups member variables in a single place, while I am here.

llvm-svn: 297850

Became possible after r297844

llvm-svn: 297848

Patch splits In<ELFT> into 2 classes: one for non-templated sections, 
second contains ELFT templated ones.
That allows to code that was detemplated to access non-templated sections freely,
and should open road for futher detemplation proccess.

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

llvm-svn: 297844

llvm-svn: 297831

llvm-svn: 297829

After introducing Config->is64Bit() and 
recent changes in LinkerScriptBase, some
sections can be detemplated trivially. This 
is one of such cases.

llvm-svn: 297825

StringTableSection was <ELFT> templated previously,

It disallow to de-template code that uses it,
for example LinkerScript<ELFT>::discard uses it as:
if (S == In<ELFT>::ShStrTab)
  error("discarding .shstrtab section is not allowed");

It seems we can try to detemplate some of synthetic sections
and somehow make them available for non-templated calls.
(move out of In<ELFT> struct probably).

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

llvm-svn: 297815

That removes CopyRelSection class completely, making
Bss/BssRelRo to be just regular synthetics.

This is splitted from D30541 and polished.
Difference from D30541 that all logic of SharedSymbol
converting to DefinedRegular was removed for now and
probably will be posted as separate patch.

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

llvm-svn: 297814

Patch introduces Config->is64Bit() and with help of that detemplates
GotPltSection and IgotPltSection sections

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

llvm-svn: 297813

This also requires postponing the assignment the assignment of
symbols defined in input linker scripts since those can refer to
output sections and in case we don't have a SECTIONS command, we
need to wait until all output sections have been created and
assigned addresses.

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

llvm-svn: 297802

Being passed -z notext is a pretty strong indication that the user is
OK with text relocations. This is not the same behavior as bfd, but
bfd defaults to -z notext, so it has to try to avoid text relocations
and use them as a last resort.

llvm-svn: 297789

That moves all members that s possible to move for now (all which
does not depend on ELFT templating).

After that change LinkerScript contains only 8 methods in total,
and I believe it is possible to move them all after tweaking other
parts of linker. And we will be able to have single class for 
linkerscript at the end.

llvm-svn: 297735

llvm-svn: 297734

llvm-svn: 297732

It does not use ELFT templates so can be non-virtual.

llvm-svn: 297727

It does not use ELFT templates so can be non-virtual.

llvm-svn: 297725

That makes it not dependent on virtual call,
keeping logic the same.

llvm-svn: 297723

One more step to combine LinkerScript and LinkerScriptBase.

llvm-svn: 297722

OutputSectionFactory has no ELFT templates anymore.

llvm-svn: 297720

llvm-svn: 297719

llvm-svn: 297718

llvm-svn: 297717

We can move all not templated functionality to LinkerScriptBase.
Patch do that for hasPhdrsCommands() and shows how it helps to detemplate
things in other places.

Probably we should be able to merge these 2 classes into single one after such steps.
Even if not, it still looks as reasonable cleanup for me.

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

llvm-svn: 297714

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

llvm-svn: 297713

lld crashes when .eh_frame or .eh_frame_hdr section is discarded
in linker script and there is no PHDRS directive.

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

llvm-svn: 297712