Regarding the comment, it is out of context because it describes
what it does not do there. It got too long because it was originally
two different comments that were simply merged together.
The semantics is described in fixAbsoluteSymbols, so we don't need it.
llvm-svn: 262031
BSD linker scripts contain special cases to add NOP
padding to code sections. Syntax is next:
.init:
{
KEEP (*(.init))
} =0x90909090
(0x90 is NOP)
This patch implements that functionality.
llvm-svn: 262020
https://docs.oracle.com/cd/E53394_01/html/E54766/u-etext-3c.html
It is said that:
_etext - The address of _etext is the first
location after the last read-only loadable segment.
_edata - The address of _edata is the first
location after the last read-write loadable segment.
_end - If the address of _edata is greater than the address
of _etext, the address of _end is same as the address of _edata.
In real life _end and _edata has different values for that case.
Both gold/bfd set _edata to the end of the last non SHT_NOBITS section.
This patch do the same for consistency.
It should fix the https://llvm.org/bugs/show_bug.cgi?id=26729.
Differential revision: http://reviews.llvm.org/D17601
llvm-svn: 262019
For shared libraries we allow any weak undefined symbol to eventually be
resolved, even if we never see a definition in another .so. This matches
the behavior when handling other undefined symbols in a shared library.
For executables, we require seeing a definition in a .so or resolve it
to zero. This is also similar to how non weak symbols are handled.
llvm-svn: 262017
When this code was first added it was compensating for the code deciding
to create plt entries for directly referenced functions being too aggressive.
That has since been fixed, so we don't need this anymore.
llvm-svn: 261933
R_MIPS_GOT16 relocation against local symbol requires index of a local
GOT entry which contains page address corresponds to sum of the symbol
address and addend. The addend in that case is calculated using addends
from the R_MIPS_GOT16 and paired R_MIPS_LO16 relocations.
Differential Revision: http://reviews.llvm.org/D17610
llvm-svn: 261930
This patch implements the same algorithm as LLD/COFF's ICF. I'm
not going to repeat the same description about how it works, so you
want to read the comment in ICF.cpp in this patch if you want to know
the details. This algorithm should be more powerful than the ICF
algorithm implemented in GNU gold. It can even merge mutually-recursive
functions (which is harder than one might think).
ICF is a fairly effective size optimization. Here are some examples.
LLD: 37.14 MB -> 35.80 MB (-3.6%)
Clang: 59.41 MB -> 57.80 MB (-2.7%)
The lacking feature is "safe" version of ICF. This merges all
identical sections. That is not compatible with a C/C++ language
requirement that two distinct functions must have distinct addresses.
But as long as your program do not rely on the pointer equality
(which is in many cases true), your program should work with the
feature. LLD works fine for example.
GNU gold implements so-called "safe ICF" that identifies functions
that are safe to merge by heuristics -- for example, gold thinks
that constructors are safe to merge because there is no way to
take an address of a constructor in C++. We have a different idea
which David Majnemer suggested that we add NOPs at beginning of
merged functions so that two or more pointers can have distinct
values. We can do whichever we want, but this patch does not
include neither.
http://reviews.llvm.org/D17529
llvm-svn: 261912
-r, -relocatable - Generate relocatable output
Currently does not have support for files containing
relocation sections with entries that refer to local
symbols (like rel[a].eh_frame which refer to sections
and not to symbols)
Differential revision: http://reviews.llvm.org/D14382
llvm-svn: 261838
This commit does two related thing. At first, it enumerates supported
absolute MIPS relocations in the `MipsTargetInfo<ELFT>::isRelRelative`
method. In that case the code is shorter and the case switch does not
tend to grow. At second, it prevents R_MIPS_COPY and PLT creation for
relative relocations. For almost all relative MIPS relocations like
R_MIPS_PC19_S2, R_MIPS_PCHI16 etc it does not have a sence. The only
exception is R_MIPS_PC32. GNU linker creates a copy relocation or PLT
entry for it. But I could not find any real test case uses R_MIPS_PC32
with DSO defined symbol as a target. So for now I prefer to skip this
case to simplify the LLD code.
llvm-svn: 261822
"Discarded" section is a marker for discarded sections, and we do not
use the instance except for checking its identity. In that sense, it
is just another type of a "null" pointer for InputSectionBase. So,
it doesn't have to be a real instance of InputSectionBase class.
In this patch, we no longer instantiate Discarded section but instead
use -1 as a pointer value. This eliminates a global variable which
needed initialization at startup.
llvm-svn: 261761
This is a preparation for ICF. If we merge two sections, we want to
align the merged section at the largest alignment requirement.
That means we want to update the alignment value, which was
impossible before this patch because Header is a const value.
llvm-svn: 261712
This test is flaky for more than half a year or so on buildbots
and has been causing confusion. Remove it while I'm investing the
cause.
llvm-svn: 261709
There is nothing aarch64 specific in here. If a symbol can be preempted,
we need to copy the full relocation to the dynamic linker.
If a symbol cannot be preempted, we can make the dynamic linker life
easier and produce a relative relocation.
This is directly equivalent to R_X86_64_64 to R_x86_64_RELATIVE
conversion.
llvm-svn: 261678
The .tbss section is in the middle of a PT_LOAD. Whatever treatment we
give to its address we must also give to the offset.
We were ignoring it for address computations, but not for offset.
Fixes pr26712.
llvm-svn: 261667
This patch moves BitcodeFile instantiation into createObjectFile.
Previously, we handle bitcode files outside that function and did
not handle for --whole-archive.
http://reviews.llvm.org/D17527
llvm-svn: 261663
This patch fixes the R_AARCH64_ABS64 relocation when used in shared mode,
where it requires a dynamic R_AARCH64_RELATIVE relocation. To correct set
the addend on the dynamic relocation (since it will be used by the dynamic
linker), a new TargetInfo specific hook was created (getDynRelativeAddend)
to get the correct addend based on relocation type.
The patch fixes the issues when creating shared library code against
{init,fini}_array, where it issues R_AARCH64_ABS64 relocation against
local symbols.
llvm-svn: 261651
When link-time garbage collection is in use (-gc-sections), it is
often useful to mark sections that should not be eliminated.
This is accomplished by surrounding an input section's wildcard
entry with KEEP(). Patch implements that command.
Differential revision: http://reviews.llvm.org/D17242
llvm-svn: 261616
A weak undefined should not fetch archive members, so we have to keep
the Lazy symbol.
That means the lazy symbol has to encode information about the original
weak undef.
Fixes pr25762.
llvm-svn: 261591
This reduces the .rodata of scyladb from 4501932 to 4334639 bytes (1.038
times smaller).
I don't think it is critical to support tail merging, just exact
duplicates, but given the code organization it was actually a bit easier
to support both.
llvm-svn: 261327
* Else-ifs in ScriptParser::run() replaced with std::function + map
* Reordered members of ScriptParser
Differential revision: http://reviews.llvm.org/D17256
llvm-svn: 261317
Previously, we added garbage-collected symbols to the symbol table
and filter them out when we were writing symbols to the file. In
this patch, garbage-collected symbols are filtered out from beginning.
llvm-svn: 261064
Each rule in SECTIONS commands is something like ".foo *(.baz.*)",
which instructs the linker to collect all sections whose name matches
".baz.*" from all files and put them into .foo section.
Previously, we didn't recognize the wildcard character. This patch
adds that feature.
Performance impact is a bit concerning because a linker script can
contain hundreds of SECTIONS rules, and doing pattern matching against
each rule would be too expensive. We could merge all patterns into
single DFA so that it takes O(n) to the input size. However, it is
probably too much at this moment -- we don't know whether the
performance of pattern matching matters or not. So I chose to
implement the simplest algorithm in this patch. I hope this simple
pattern matcher is sufficient.
llvm-svn: 260745
This patch adds some TLS relocations and relaxations for AArch64.
Some Global-Dynamic relocation are handled by optimizing them to
Local-Exec (Initial-Exec is not yet supported). They are:
- R_AARCH64_TLSDESC_ADR_PAGE21
- R_AARCH64_TLSDESC_LD64_LO12_NC
- R_AARCH64_TLSDESC_ADD_LO12_NC
- R_AARCH64_TLSDESC_CALL
Also some Init-Exec is optimized to Local-Exec if possible. They are:
- R_AARCH64_TLSIE_ADR_GOTTPREL_PAGE21
- R_AARCH64_TLSIE_LD64_GOTTPREL_LO12_NC
Finally some Local-Exec relocation are handled in relocateOne:
- R_AARCH64_TLSLE_ADD_TPREL_HI12
- R_AARCH64_TLSLE_ADD_TPREL_LO12_NC
This work is mainly for compiler bootstrap, where static binaries is
showing good progress (although shared object still lacking support
from both TLS aarch64 backend and some other issues).
llvm-svn: 260677
Previously, if both A and B are ".ctors", both compCtors(A, B) and
compCtors(B, A) are true, which is a violation of the strict weak
ordering because such function is not antisymmetric.
llvm-svn: 260633
Previously, Target held a value until a new value is assigned to the
variable. That was a benign leak -- that was not an unbounded leak
and didn't grab any resources except a small amount of memory. But
it is better to fix than leaving as is.
llvm-svn: 260592
Previously, we had code for linker scripts in Writer. This patch
separates that as LinkerScript class. The class provides a few
functions to query linker scripts and is also a container of some
linker-script-specific information.
Hopefully, Writer will only implement the default behavior and let
the new class handle gotchas regarding linker scripts.
llvm-svn: 260591
R_X86_64_TPOFF64 is a dynamic relocation,
it should not appear in static relocation processing.
Patch fixes it.
Differential revision: http://reviews.llvm.org/D16880
llvm-svn: 260508
They don't count for the memory or file size, so this is mostly just a
simplification.
The only noticeable difference should be fewer empty program headers.
llvm-svn: 260465
Global constructors and destructors are guaranteed to be called
in the order as they appear in a translation unit. So we don't want
to mess up the order if they have the same priority.
llvm-svn: 260463
IMHO this makes the code easier to read and should help with linker
scripts.
This is strongly based on D16575. The main differences are:
We record a range of sections, not every section in a program header.
scanHeaders takes case of deciding what goes in every program header,
including PT_GNU_RELRO
We create dummy sections for the start of the file
With this, program header creation has 3 isolated stages:
Map sections to program headers.
Assign addresses to *sections*
Looking at sections find the address and size of each program header.
Thanks to George Rimar for the initial version.
llvm-svn: 260453
We have a vector of all of the compact unwind entries anyway, and
its live as long as we need it to be. So instead of copying from that
vector to another, just take references to the range of the original vector
we need for each compact unwind page.
llvm-svn: 260437
The patch adds lazy relocation support for MIPS and R_MIPS_26 relocation
handing.
R_MIPS_26 relocation might require PLT entry creation. In that case it
is fully supported by the patch. But if the relocation target is a local
symbol we need to use a different expression to calculate the relocation
result. This case is not implemented yet because there is no method to
get know the kind of relocation target in the `relocateOne` routine.
Differential Revision: http://reviews.llvm.org/D16982
llvm-svn: 260424
MIPS 32-bit ABI uses REL relocation record format. We read addends from
relocation destinations right in the MipsTargetInfo::relocateOne
function.
llvm-svn: 260364
This basically reverts commit r260073 because it is found that
augmentation strings don't always start with "zR". It is reported
as https://llvm.org/bugs/show_bug.cgi?id=26541.
llvm-svn: 260294
The non lazy atoms generated in the stubs pass use an image cache to
hold all of the pointers. On arm archs, this is the __got section,
but on x86 archs it should be __nl_symbol_ptr.
rdar://problem/24572729
llvm-svn: 260271
ld64 aligns most of the stub's to 2 byte alignment, expect for
the stub helper common atoms which are 4 byte aligned.
This adds a new field to StubInfo which tracks this alignment
and ensures that this is the alignment we get in the final image.
rdar://problem/24570220
llvm-svn: 260248
This is the function equivalent of a copy relocation.
Since functions are expected to change sizes, we cannot use copy
relocations. In situations where one would be needed, what is done
instead is:
* Create a plt entry
* Output an undefined symbol whose addr is the plt entry.
The dynamic linker makes sure any shared library uses the plt entry as
the function address.
llvm-svn: 260224
Also added the defaults for whether to generate this load command, which
the cmdline options are able to override.
There was also a difference to ld64 which is fixed here in that ld64 will
generate an empty data in code command if requested.
rdar://problem/24472630
llvm-svn: 260191
This load command generates data in the LINKEDIT section which
is a list of ULEB128 delta's to all of the functions in the __text section.
It is then 0 terminated and pointer aligned to pad.
ld64 exposes the -function-starts and no-function-starts cmdline options
to override behaviour from the defaults based on file types.
rdar://problem/24472630
llvm-svn: 260188
This was a bug in our handling of these symbols compared to ld64.
Turns out that ld64 always marks these symbols as being not dead stripped.
llvm-svn: 260185
The atom content type enum is used as a tie breaker to sort atoms.
In that case, we want MachHeader to be before typeCode as it really will
be before the code in the final executable.
Test case to follow in the next commit or two.
llvm-svn: 260184
I found that the handling of 'L' character in an augmentation string is
wrong because 'L' means that the next byte is the length field. I could
have fixed that by just skipping the next byte, but I decided to take a
different approach.
Teaching the linker about all the types of CIE internal records just to
skip them is silly. And the code doing that is not actually executed now
(that's why the bug did not cause any issue.) It is because the 'R' field,
which we want to read, is always at beginning of the CIE. So I reduced
the code dramatically by assuming that that's always the case. I want to
see how it works in the wild. If it doesn't work, we can roll this back
(with a fix for 'L').
http://reviews.llvm.org/D16939
llvm-svn: 260073
The initial segment protection was also being used to set the maximum
segment protection level. Instead, the maximum should be set according
to the architecture we are linking. For example on Mac OS it should be
RWX on most pages, but on iOS is often on R_X.
rdar://problem/24515136
llvm-svn: 259966
We currently tag on a "__LINKEDIT" when we are emitting the segments.
However, an upcoming patch aims to set the initprot and maxprot segment members
to their correct values, and in order to share code, its better to create this
segment for real and handle it in buildFileOffsets the same way ld64 does.
The commit for segment protections will add a test for this all being correct so
no test here until that code is committed.
llvm-svn: 259960
I removed "CIE/FIE size is too large" error because that was not
checking for correct error conditions. [UINT_MAX - 4, UINT_MAX) is
a correct range as a size of a CIE/FDE record. It's just that the
size cannot be larger than the section size.
llvm-svn: 259951
Previously, it was easy to leave some Out<ELFT> fields uninitialized
because assignments to the fields are mixed with output section
instantiations. In this patch, I separate initializations from assignments
to improve readability.
http://reviews.llvm.org/D16864
llvm-svn: 259899
The variable was marking various cases where a symbol must be included
in the dynamic symbol table. Being used by a dynamic relocation was only
one of them.
llvm-svn: 259889
The previous names contained "Local" and "Current", but what we
are handling is always local and current, so they were redundant.
TlsIndex comes from "tls_index" struct that Ulrich Drepper is using
in this document to describe this data structure in GOT.
llvm-svn: 259852
Summary:
LLVM3.3 (and earlier) would fail to include a relocation section in
the group that the section it was relocating is in. Object files
affected by this issue have been encountered in the wild when using LLD.
This would result in a siutation like:
Section {
Index: 5
Name: .text._Z3fooIiEvv (6)
Type: SHT_PROGBITS (0x1)
Flags [ (0x206)
SHF_ALLOC (0x2)
SHF_EXECINSTR (0x4)
SHF_GROUP (0x200)
]
Address: 0x0
Offset: 0x48
Size: 5
Link: 0
Info: 0
AddressAlignment: 1
EntrySize: 0
}
Section {
Index: 6
Name: .rela.text._Z3fooIiEvv (1)
Type: SHT_RELA (0x4)
Flags [ (0x0)
]
Address: 0x0
Offset: 0x3F0
Size: 24
Link: 8
Info: 5
AddressAlignment: 8
EntrySize: 24
}
In LLD, during symbol resolution, we discard the section containing the
weak symbol, but this amounts to replacing it with
InputSection<ELFT>::Discarded.
When we later saw the corresponding relocation section, we would then
end up pusing onto InputSection<ELFT>::Discarded.RelocSections, which is
bogus.
Reviewers: ruiu, rafael
Subscribers: llvm-commits, Bigcheese
Differential Revision: http://reviews.llvm.org/D16898
llvm-svn: 259831
Another case where we currently have almost duplicated code is the
creation of dynamic relocations. First to decide if we need one, then to
decide what to write.
This patch fixes it by passing more information from the relocation scan
to the section writing code. This is the same idea used for r258723.
I actually think it should be possible to simplify this further by
reordering things a bit in the writer. For example, we should be able to
represent almost every position in the file with an OutputSeciton and
offset. When writing it out we then just need to add the offset to the
OutputSection VA.
llvm-svn: 259829
On Mac OS 10.5 and later, with X86_64 and outputting a dynamic executable,
ld64 set the CPU_SUBTYPE_LIB64 mask on the cpusubtype in the mach_header.
This adds the same functionality to lld.
rdar://problem/24507177
llvm-svn: 259826
Symbol does not need an entry i the 'global' part of GOT if it cannot be
preempted. So canBePreempted fully satisfies us at least for now.
llvm-svn: 259779
If relocation against symbol requires GOT entry creation and this symbol
is defined in DSO, the GOT entry should be created in the 'global' part
of the GOT even if we link executable file. Also we do not need to create
a dynamic symbol table entry for global symbol corresponding to the
local GOT entry.
llvm-svn: 259778
This is of the form A.B.C.D.E and to match ld64's behaviour, is
always output to files, even when the version is 0.
rdar://problem/24472630
llvm-svn: 259746
ld64 sets both S_ATTR_PURE_INSTRUCTIONS and S_ATTR_SOME_INSTRUCTIONS
on __TEXT, __text. We only had the S_ATTR_PURE_INSTRUCTIONS attribute.
rdar://problem/24495801
llvm-svn: 259744
In the case where we are emitting to an object file, the platform is
possibly unknown, and the source object files contained load commands
for version min, we can take the maximum of those min versions and
emit in in the output object file.
This test also tests r259739.
llvm-svn: 259742
Defaulting to unknown matches ld64, but it also makes sure that all
of our code can handle not knowing the platform. For example, a later
commit will add support for version min load commands with an unknown
platform, which is a feature supported by ld64.
No test case here. The next commit will have one with the version min
code that needed this patch.
llvm-svn: 259739
This option is emitted in the min_version load commands.
Note, there's currently a difference in behaviour compared to ld64 in
that we emit a warning if we generate a min_version load command and
didn't give an sdk_version. We need to decide what the correct behaviour
is here as its possible we want to emit an error and force clients to
provide the option.
llvm-svn: 259729
If the command line contains something like -macosx_version_min and we
don't explicitly disable generation with -no_version_load_command then
we generate the LC_VERSION_MIN command in the output file.
There's a couple of FIXME's in here. These will be handled soon with
more tests but I didn't want to grow this patch any more than it already was.
rdar://problem/24472630
llvm-svn: 259718
On some Windows environment, this test did not fail, because opening NUL
with FileOutputBuffer didn't fail. Thanks to George Rimar for reporting.
llvm-svn: 259669
It can fail to open an output file for various reasons, including
lack of permission, too long filename, or the output file is not
a mmap'able file.
llvm-svn: 259596
In r259574 I fixed some of the issues with the mach header symbols
and DSO handles.
This is the next issue whereby the __mh_execute_header has to not
be dead stripped, and (to match ld64) should be dynamically referenced.
The test here should also have been added in r259574 to make sure that
we emit this symbol. But checking that it is not only emitted but also
has the correct reference type is fine.
llvm-svn: 259589
The magic file which contained these symbols inherited from archive
which meant that the resolver didn't add the required atoms as archive
members only get added when referenced. Instead we now inherit from
SimpleFile which always links in the atoms needed.
The second issue was in the handling of these symbols when we emit
the MachO. The mach header symbol needs to be in the atom list as
it gets an offset (0), and being in the atom list makes sure it is
emitted to the symbol table. DSO handles are not emitted to the
symbol table.
rdar://problem/24450654
llvm-svn: 259574
Previously, we used both single quotes and double quotes, and
some single-quoted tokens are concatenated with next tokens because
there were no spaces between them. That may be a cause of test flakiness
on Windows, which is reported as https://llvm.org/bugs/show_bug.cgi?id=26388.
The new test commands are more straightforward than before.
llvm-svn: 259559
This patch adds "Error" field to LinkerScript class. That field
is false by default, and set to true if there is a syntax error
in an input file. The linker script parser is a recursive-descedent
parser. Each function returns if Error is true -- so that
eventually the whole parser returns to a caller.
http://reviews.llvm.org/D16667
llvm-svn: 259557
All MemoryBuffers for archive files are guaranteed to exist as long
as their children are used in the linker. So we don't need to copy
strings here. Thanks to Sean Silva for pointing this out.
llvm-svn: 259554
-Bsymbolic-functions:
When creating a shared library, bind references to global
function symbols to the definition within the shared library, if any.
This patch also fixed behavior of already existent -Bsymbolic:
previously PLT entries were created even if -Bsymbolic was specified.
Differential revision: http://reviews.llvm.org/D16411
llvm-svn: 259481
Some dynamic table tags like RELSZ and PLTRELSZ depens on result of
finalizing corresponding relocation sections. Therefore we have to
finalize .dynamic section at the end.
Differential Revision: http://reviews.llvm.org/D16799
llvm-svn: 259478
If object files are drawn from archive files, the error message should
be something like "conflict symbols in foo.a(bar.o) and baz.o" instead
of "conflict symbols in bar.o and baz.o". This patch implements that.
llvm-svn: 259475
When we do debug printing of atoms, they expect their parent file
to have an ordinal. Right now we trigger a bunch of asserts.
This doesn't actually manifest in differences in any real tests, but
even if the only thing it does is improve debuggability then its still
useful.
llvm-svn: 259450
Instead of leave unused fields as is, set them to nullptr.
Currnetly this is NFC, but if you call writeResults more than
once, you should be able to see the difference.
llvm-svn: 259444
The ObjCPass is going to need to create pointer sized relocations in
the ObjC sections. This method will be used to give us a target independent
way of getting the correct kind for the refererence.
llvm-svn: 259441
An upcoming patch will use this to create lists of ObjC methods.
Adding it now to reduce the amount of code in that patch.
Test cases will follow in the other patch too.
llvm-svn: 259440
This adds the no_objc_category_merging cmdline option which will
be used in an upcoming commit to disable the category optimizer.
It is on by default in ld64 so we match that here.
Test case will come soon with the patch to make use of this option.
llvm-svn: 259439
Most of the other methods to access Reference's were on DefinedAtom so
this just keeps them all together.
This will be used in a future patch in ObjCPass which needs to add
new references. The method is virtual because we may add references to
different data structures depending on whether we parsed a macho file or
yaml.
llvm-svn: 259436
This will be used by a future commit which wanted to compare iterators
for equality.
Also changed operator!= to be in terms of the new operator==
llvm-svn: 259431
Rafael Espindola