This is a part of ttps://bugs.llvm.org//show_bug.cgi?id=38119
We produce broken ELF header now when the number of output sections is >= SHN_LORESERVE (0xff00).
ELF spec says (http://www.sco.com/developers/gabi/2003-12-17/ch4.eheader.html):
e_shnum:
If the number of sections is greater than or equal to SHN_LORESERVE (0xff00), this member has the value zero
and the actual number of section header table entries is contained in the sh_size field of the section header at index 0.
(Otherwise, the sh_size member of the initial entry contains 0.)
e_shstrndx
If the section name string table section index is greater than or equal to SHN_LORESERVE (0xff00), this member has the
value SHN_XINDEX (0xffff) and the actual index of the section name string table section is contained in the sh_link field of
the section header at index 0. (Otherwise, the sh_link member of the initial entry contains 0.)
We did not set these fields correctly earlier. The patch fixes the issue.
Differential revision: https://reviews.llvm.org/D49371
llvm-svn: 337363
This patch merges createGdbIndex function and GdbIndexSection's
constructor into a single static member function of the class.
This patch also change how we keep CU vectors. Previously, CuVector
and GdbSymbols were parallel arrays, but there's no reason to choose that
design. Now, CuVector is a member of GdbSymbol class.
A lot of members are removed from GdbIndexSection. Previously, it has
members that need to be kept in sync over several phases. I belive the new
design is less error-prone, and the new code is much easier to read
than before.
llvm-svn: 336743
Patch by Matthew Koontz!
Before, direct calls to __wrap_sym would not map to valid PLT entries,
so they would crash at runtime. This change maps such calls to the same
PLT entry as calls to sym that are then wrapped.
Differential Revision: https://reviews.llvm.org/D48502
llvm-svn: 336609
Patch by Rahul Chaudhry!
This change adds experimental support for SHT_RELR sections, proposed
here: https://groups.google.com/forum/#!topic/generic-abi/bX460iggiKg
Pass '--pack-dyn-relocs=relr' to enable generation of SHT_RELR section
and DT_RELR, DT_RELRSZ, and DT_RELRENT dynamic tags.
Definitions for the new ELF section type and dynamic array tags, as well
as the encoding used in the new section are all under discussion and are
subject to change. Use with caution!
Pass '--use-android-relr-tags' with '--pack-dyn-relocs=relr' to use
SHT_ANDROID_RELR section type instead of SHT_RELR, as well as
DT_ANDROID_RELR* dynamic tags instead of DT_RELR*. The generated
section contents are identical.
'--pack-dyn-relocs=android+relr --use-android-relr-tags' enables both
'--pack-dyn-relocs=android' and '--pack-dyn-relocs=relr': lld will
encode the relative relocations in a SHT_ANDROID_RELR section, and pack
the rest of the dynamic relocations in a SHT_ANDROID_REL(A) section.
Differential Revision: https://reviews.llvm.org/D48247
llvm-svn: 336594
Currently, there are only OutputSection and SymbolAssignment
commands possible at the first level under SECTIONS tag.
So, shouldSkip() contained dead "return true".
Patch simplifies the code.
llvm-svn: 336282
This is PR36768.
Linker script OVERLAYs are described in 4.6.9. Overlay Description of the spec:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Using_ld_the_GNU_Linker/sections.html
They are used to allow output sections which have different LMAs but the same VAs
and used for embedded programming.
Currently, LLD restricts overlapping of sections and that seems to be the most desired
behaviour for defaults. My thoughts about possible approaches for PR36768 are on the bug page,
this patch implements OVERLAY keyword and allows VAs overlapping for sections that within the overlay.
Differential revision: https://reviews.llvm.org/D44780
llvm-svn: 335714
This generalizes the old heuristic placing SHT_DYNSYM SHT_DYNSTR first in the readonly SHF_ALLOC segment.
Reviewers: espindola
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D48406
llvm-svn: 335674
Summary:
Currently when --no-rosegment is specified or a linker script with SECTIONS command is used,
.rodata (A) .text (AX) are assigned the same rank and .rodata may be placed after .text .
This increases the gap between .text and .bss and can cause pc-relative relocation overflow (e.g. gcc crtbegin.o crtbegin.S have R_X86_64_PC32 relocation from .text to .bss).
This patch makes SingleRoRx affect only segment layout, not section layout. As a consequence, .rodata will be placed before .text regardless of SingleRoRx.
Reviewers: espindola, ruiu, grimar, echristo, javed.absar
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D48405
llvm-svn: 335627
Almost all entries inside MIPS GOT are referenced by signed 16-bit
index. Zero entry lies approximately in the middle of the GOT. So the
total number of GOT entries cannot exceed ~16384 for 32-bit architecture
and ~8192 for 64-bit architecture. This limitation makes impossible to
link rather large application like for example LLVM+Clang. There are two
workaround for this problem. The first one is using the -mxgot
compiler's flag. It enables using a 32-bit index to access GOT entries.
But each access requires two assembly instructions two load GOT entry
index to a register. Another workaround is multi-GOT. This patch
implements it.
Here is a brief description of multi-GOT for detailed one see the
following link https://dmz-portal.mips.com/wiki/MIPS_Multi_GOT.
If the sum of local, global and tls entries is less than 64K only single
got is enough. Otherwise, multi-got is created. Series of primary and
multiple secondary GOTs have the following layout:
```
- Primary GOT
Header
Local entries
Global entries
Relocation only entries
TLS entries
- Secondary GOT
Local entries
Global entries
TLS entries
...
```
All GOT entries required by relocations from a single input file
entirely belong to either primary or one of secondary GOTs. To reference
GOT entries each GOT has its own _gp value points to the "middle" of the
GOT. In the code this value loaded to the register which is used for GOT
access.
MIPS 32 function's prologue:
```
lui v0,0x0
0: R_MIPS_HI16 _gp_disp
addiu v0,v0,0
4: R_MIPS_LO16 _gp_disp
```
MIPS 64 function's prologue:
```
lui at,0x0
14: R_MIPS_GPREL16 main
```
Dynamic linker does not know anything about secondary GOTs and cannot
use a regular MIPS mechanism for GOT entries initialization. So we have
to use an approach accepted by other architectures and create dynamic
relocations R_MIPS_REL32 to initialize global entries (and local in case
of PIC code) in secondary GOTs. But ironically MIPS dynamic linker
requires GOT entries and correspondingly ordered dynamic symbol table
entries to deal with dynamic relocations. To handle this problem
relocation-only section in the primary GOT contains entries for all
symbols referenced in global parts of secondary GOTs. Although the sum
of local and normal global entries of the primary got should be less
than 64K, the size of the primary got (including relocation-only entries
can be greater than 64K, because parts of the primary got that overflow
the 64K limit are used only by the dynamic linker at dynamic link-time
and not by 16-bit gp-relative addressing at run-time.
The patch affects common LLD code in the following places:
- Added new hidden -mips-got-size flag. This flag required to set low
maximum size of a single GOT to be able to test the implementation using
small test cases.
- Added InputFile argument to the getRelocTargetVA function. The same
symbol referenced by GOT relocation from different input file might be
allocated in different GOT. So result of relocation depends on the file.
- Added new ctor to the DynamicReloc class. This constructor records
settings of dynamic relocation which used to adjust address of 64kb page
lies inside a specific output section.
With the patch LLD is able to link all LLVM+Clang+LLD applications and
libraries for MIPS 32/64 targets.
Differential revision: https://reviews.llvm.org/D31528
llvm-svn: 334390
PPC64 maintains a compiler managed got in the .toc section. When accessing a
global variable through got-indirect access, a .toc entry is created for the
variable. The relocation for the got-indirect access will refer to the .toc
section rather than the symbol that is actually accessed. The .toc entry
contains the address of the global variable. We evaluate the offset from
r2 (which is the TOC base) to the address of the toc entry for the global
variable. Currently, the .toc is not near the .got. This causes errors because
the offset from r2 to the toc section is too large. The linker needs to add
all the .toc input sections to the .got output section, merging the compiler
managed got with the linker got. This ensures that the offsets from the TOC
base to the toc entries are not too large.
This patch puts the .toc section right after the .got section.
Differential Revision: https://reviews.llvm.org/D45833
llvm-svn: 333199
Note that this doesn't do the right thing in the case where there is
a linker script. We probably need to move output section assignment
before ICF to get the correct behaviour here.
Differential Revision: https://reviews.llvm.org/D47241
llvm-svn: 333052
_init_array_start/end are placed at 0 if no ".init_array" presents,
this causes .text relocation against them become more prone to overflow.
This CL sets ".init_array" address to that of ".text" to mitigate the situation.
Review: https://reviews.llvm.org/D46200
llvm-svn: 332688
This CL places .dynsym and .dynstr at the beginning of SHF_ALLOC
sections. We do this to mitigate the possibility that huge .dynsym and
.dynstr sections placed between ro-data and text sections cause
relocation overflow.
Differential Revision: https://reviews.llvm.org/D45788
llvm-svn: 332374
This CL is to mitigate R_X86_64_PC32 relocation overflow problems for huge binaries that has near 4G allocated sections.
By examining those binaries, there're 2 issues contributes to the problem:
1). huge ".dynsym" and ".dynstr" stands in the way between .rodata and .text
2). _init_array_start/end are placed at 0 if no ".init_array" presents, this causes .text relocation against them become more prone to overflow.
This CL addresses 1st problem (the 2nd will be addressed in another CL.) by assigning a smaller sortrank to .dynsym and .dynstr thus they no longer stand in between.
llvm-svn: 332038
A non-alloc note section should not have a PT_NOTE program header.
Found while linking ghc (Haskell compiler) with lld on FreeBSD.
ghc emits a .debug-ghc-link-info note section (as the name suggests, it
contains link information) as a SHT_NOTE section without SHF_ALLOC set.
For this case ld.bfd does not emit a PT_NOTE segment for the
.debug-ghc-link-info section. lld previously emitted a PT_NOTE with
p_vaddr = 0 and FreeBSD's rtld segfaulted when trying to parse a note at
address 0.
llvm.org/pr37361
Differential Revision: https://reviews.llvm.org/D46623
llvm-svn: 331973
Separate output sections for selected text section prefixes to enable TLB optimizations and for readablilty.
Differential Revision: https://reviews.llvm.org/D45841
llvm-svn: 331823
The current support for V1 ABI in LLD is incomplete.
This patch removes V1 ABI support and changes the default behavior to V2 ABI,
issuing an error when using the V1 ABI. It also updates the testcases to V2
and removes any V1 specific tests.
Differential Revision: https://reviews.llvm.org/D46316
llvm-svn: 331529
This is slightly simpler to read IMHO. Now if a symbol has a position
in the file, it is Defined.
The main motivation is that with this a SharedSymbol doesn't need a
section, which reduces the size of SymbolUnion.
With this the peak allocation when linking chromium goes from 568.1 to
564.2 MB.
llvm-svn: 330966
It turns out we should not use the std::sort anymore.
r327219 added a new wrapper llvm::sort (D39245).
When EXPENSIVE_CHECKS is defined, it shuffles the
input container and that helps to find non-deterministic
ordering.
Patch changes code to use llvm::sort and std::stable_sort
instead of std::sort
Differential revision: https://reviews.llvm.org/D45969
llvm-svn: 330702
We had a single symbol using -1 with a synthetic section. It is
simpler to just update its value.
This is not a big will by itself, but will allow having a simple
getOffset for InputSeciton.
llvm-svn: 330340
Currently LLD sets OutSecOff in addSection for input sections.
That is a fake offset (just a rude approximation to remember the order),
used for sorting SHF_LINK_ORDER sections
(see resolveShfLinkOrder, compareByFilePosition).
There are 2 problems with such approach:
1. We currently change and reuse Size field as a value assigned. Changing size is
not good because leads to bugs. Currently, SIZEOF(.bss) for empty .bss returns 2
because we add two empty synthetic sections and increase size twice by 1.
(See PR37011: https://bugs.llvm.org/show_bug.cgi?id=37011)
2. Such approach simply does not work when --symbol-ordering-file is involved,
because processing of the ordering file might break the initial section order.
This fixes PR37011.
Differential revision: https://reviews.llvm.org/D45368
llvm-svn: 329560
This is for PR36716 and
this enables emitting STT_FILE symbols.
Output size affect is minor:
lld binary size changes from 52,883,408 to 52,949,400
clang binary size changes from 83,136,456 to 83,219,600
Differential revision: https://reviews.llvm.org/D45261
llvm-svn: 329557
Currently there are a few odd things about the warning about symbols
that cannot be ordered. This patch fixes:
* When there is an undefined symbol that resolves to a shared file, we
were printing the location of the undefined reference.
* If there are multiple comdats, we were reporting them all.
llvm-svn: 329371
Added checks to test that we do not produce
output where VA of sections overruns the address
space available.
Differential revision: https://reviews.llvm.org/D43820
llvm-svn: 329063
It generally does not matter much where we place sections ordered
by --symbol-ordering-file relative to other sections. But if the
ordered sections are hot (which is the case already for some users
of --symbol-ordering-file, and is increasingly more likely to be
the case once profile-guided section layout lands) and the target
has limited-range branches, it is beneficial to place the ordered
sections in the middle of the output section in order to decrease
the likelihood that a range extension thunk will be required to call
a hot function from a cold function or vice versa.
That is what this patch does. After D44966 it reduces the size of
Chromium for Android's .text section by 60KB.
Differential Revision: https://reviews.llvm.org/D44969
llvm-svn: 328905
This patch fixes an issue introduced in r328810 which made the algorithm
to always run the loop O(n^2) times, though we can break early. The
output remains the same.
llvm-svn: 328811
There are no reasons for them to be STV_DEFAULT,
recently bfd did the same change.
Differential revision: https://reviews.llvm.org/D44566
llvm-svn: 327983
This patch adds changes to start supporting the Power 64-Bit ELF V2 ABI.
This includes:
- Changing the ElfSym::GlobalOffsetTable to be named .TOC.
- Creating a GotHeader so the first entry in the .got is .TOC.
- Setting the e_flags to be 1 for ELF V1 and 2 for ELF V2
Differential Revision: https://reviews.llvm.org/D44483
llvm-svn: 327871
This is the same as 327248 except Arm defining _GLOBAL_OFFSET_TABLE_ to
be the base of the .got section as some existing code is relying upon it.
For most Targets the _GLOBAL_OFFSET_TABLE_ symbol is expected to be at
the start of the .got.plt section so that _GLOBAL_OFFSET_TABLE_[0] =
reserved value that is by convention the address of the dynamic section.
Previously we had defined _GLOBAL_OFFSET_TABLE_ as either the start or end
of the .got section with the intention that the .got.plt section would
follow the .got. However this does not always hold with the current
default section ordering so _GLOBAL_OFFSET_TABLE_[0] may not be consistent
with the reserved first entry of the .got.plt.
X86, X86_64 and AArch64 will use the .got.plt. Arm, Mips and Power use .got
Fixes PR36555
Differential Revision: https://reviews.llvm.org/D44259
llvm-svn: 327823
This change broke ARM code that expects to be able to add
_GLOBAL_OFFSET_TABLE_ to the result of an R_ARM_REL32.
I will provide a reproducer on llvm-commits.
llvm-svn: 327688
This is an option to print out a table of symbols and filenames.
The output format of this option is the same as GNU, so that it can be
processed by the same scripts as before after migrating from GNU to lld.
This option is mildly useful; we can live without it. But it is pretty
convenient sometimes, and it can be implemented in 50 lines of code, so
I think lld should support this option.
Differential Revision: https://reviews.llvm.org/D44336
llvm-svn: 327565
This is part of PR36515.
With some linkerscripts it is possible to get file offset overlaps
and overflows. Currently LLD checks overlaps in checkNoOverlappingSections().
And also we allow broken output with --no-inhibit-exec.
Problem is that sometimes final offset of sections is completely broken
and we calculate output file size wrong and might crash.
Patch implements check to verify that there is no output section
which offset exceeds file size.
Differential revision: https://reviews.llvm.org/D43819
llvm-svn: 327376
the start of the .got.plt section so that _GLOBAL_OFFSET_TABLE_[0] =
reserved value that is by convention the address of the dynamic section.
Previously we had defined _GLOBAL_OFFSET_TABLE_ as either the start or end
of the .got section with the intention that the .got.plt section would
follow the .got. However this does not always hold with the current
default section ordering so _GLOBAL_OFFSET_TABLE_[0] may not be consistent
with the reserved first entry of the .got.plt.
X86, X86_64, Arm and AArch64 will use the .got.plt. Mips and Power use .got
Fixes PR36555
Differential Revision: https://reviews.llvm.org/D44259
llvm-svn: 327248
It was raised during the review of D43819.
LLD usually use [X, Y] for reporting ranges, like below:
"relocation R_386_16 out of range: 65536 is not in [0, 65535]"
Patch changes rangeToString() to do the same.
Differential revision: https://reviews.llvm.org/D44207
llvm-svn: 326918
Summary:
I originally tried to simplify code and then noticed that lld doesn't
do what it tells to the user by warn(). It says "unable to order
discarded symbol" but it actually can for sections eliminated by ICF.
With this patch, lld doesn't sort such sections.
Reviewers: jhenderson, rafael
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D44180
llvm-svn: 326911
Previously, we didn't try to make effort to put .note sections next
to each other in the output file, so two .note sections were likely
to be stored to two separate NOTE segments. That's undesirable because
we should create as few segments as possible in general.
Differential Revision: https://reviews.llvm.org/D43858
llvm-svn: 326410
This should resolve the issue that lld build fails in some hosts
that uses case-insensitive file system.
Differential Revision: https://reviews.llvm.org/D43788
llvm-svn: 326339
Imagine that we have sections A, B, C, where A == C and
symbol ordering file containing symbols: symC, symB, symA
Previously because of ICF it was possible that final order would be
B, A or B, C. That violates order specified in ordering file.
Patch changes that.
Differential revision: https://reviews.llvm.org/D43234
llvm-svn: 326179
This fixes pr36475.
I think this code can be simplified a bit, but I would like to check
in the more direct fix if we are in agreement on the direction and
then refactor.
This is not something that bfd does. The issue is not noticed in bfd
because it keeps fewer sections from the linkerscript in the output.
The reasons why it seems reasonable to do this:
- As George noticed, we would still keep the flags if the output
section had both an empty synthetic section and a regular section
- We need an heuristic to find the flags of output sections. Using the
flags of a synthetic section that would have been there seems a
reasonable heuristic.
llvm-svn: 326137
MIPS ABIs require that if an executable file uses non-PIC model, the
EI_ABIVERSION entry in the ELF header should be incremented from 0 to 1.
That allows obsoleted / limited dynamic linkers refuse to link them.
llvm-svn: 325890
This continues direction started in D43069.
We can keep sections that are explicitly assigned to segment in script.
It helps to simplify code.
Differential revision: https://reviews.llvm.org/D43571
llvm-svn: 325887
We sometimes need to iterate over input sections for a given
output section. It is not very convinent because we have to iterate
over section descriptions.
Patch introduces getInputSections helper, it simplifies things.
Differential revision: https://reviews.llvm.org/D43574
llvm-svn: 325763
There are a number of different situations when symbols are requested
to be ordered in the --symbol-ordering-file that cannot be ordered for
some reason. To assist with identifying these symbols, and either
tidying up the order file, or the inputs, a number of warnings have
been added. As some users may find these warnings unhelpful, due to how
they use the symbol ordering file, a switch has also been added to
disable these warnings.
The cases where we now warn are:
* Entries in the order file that don't correspond to any symbol in the input
* Undefined symbols
* Absolute symbols
* Symbols imported from shared objects
* Symbols that are discarded, due to e.g. --gc-sections or /DISCARD/ linker script sections
* Multiple of the same entry in the order file
Reviewed by: rafael, ruiu
Differential Revision: https://reviews.llvm.org/D42475
llvm-svn: 325125
We sort inside output sections, so all the sections we see should be
InputSectionBase.
I noticed the patch adding callgraph based section ordering used this
type and changing this separately makes the merge easier.
llvm-svn: 325094
When decompressing a compressed debug section, we drop SHF_COMPRESSED
flag but we didn't drop "z" in ".zdebug" section name. This patch does
that for consistency.
This change also fixes the issue that .zdebug_gnu_pubnames are not
dropped when we are creating a .gdb_index section.
llvm-svn: 324949
This is a bit more verbose, but it has a few advantages.
The logic on what to do with special sections like .init_array is not
duplicated. Before we would need keep isKnownNonreorderableSection in
sync.
I think with this the call graph based sorting can be implemented by
"just" returning a new order from buildSectionOrder.
llvm-svn: 324744
This is PR35740 which now crashes
because we remove unused synthetic sections incorrectly.
We can keep input section description and corresponding output
section live even if it must be empty and dead.
This results in a crash because SHF_LINK_ORDER handling code
tries to access first section which is nullptr in this case.
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D42681
llvm-svn: 324463
In lld this was the only use of Config->Static where it meant anything
else other than "use .a instead of .so".
If a program turns out to not use any dynamic libraries, we should
produce the same result with and without -static.
llvm-svn: 324421
Summary:
While trying to make a linker script behave the same way with lld as it did
with bfd, I discovered that lld currently doesn't diagnose overlapping
output sections. I was getting very strange runtime failures which I
tracked down to overlapping sections in the resulting binary. When linking
with ld.bfd overlapping output sections are an error unless
--noinhibit-exec is passed and I believe lld should behave the same way
here to avoid surprising crashes at runtime.
The patch also uncovered an errors in the tests: arm-thumb-interwork-thunk
was creating a binary where .got.plt was placed at an address overlapping
with .got.
Reviewers: ruiu, grimar, rafael
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D41046
llvm-svn: 323856
This should fix PR36017.
The root problem is that we were creating a PT_LOAD just for the
header. That was technically valid, but inconvenient: we should not be
making the ELF discontinuous.
The solution is to allow a section with LMAExpr to be added to a
PT_LOAD if that PT_LOAD doesn't already have a LMAExpr.
llvm-svn: 323625
This fixes the crash reported at PR36083.
The issue is that we were trying to put all the sections in the same
PT_LOAD and crashing trying to write past the end of the file.
This also adds accounting for used space in LMARegion, without it all
3 PT_LOADs would have the same physical address.
llvm-svn: 323449
Since SyntheticSection::getParent() may return null, dereferencing
this pointer in ARMExidxSentinelSection::empty() call from
removeUnusedSyntheticSections() results in crashes when linking ARM
binaries.
Patch by vit9696!
llvm-svn: 323366
Previously we checked (HeaderSize == 0) to find out if
PltSection section is IPLT or PLT. Some targets does not set
HeaderSize though. For example PPC64 has no lazy binding implemented
and does not set PltHeaderSize constant.
Because of that using of both IPLT and PLT relocations worked
incorrectly there (testcase is provided).
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D41613
llvm-svn: 322362
Currently LLVM's paralellForEach has a problem with reentracy.
That caused https://bugs.llvm.org/show_bug.cgi?id=35788 (lld somtimes
hangs while linking Ruby 2.4) because maybeCompress calls writeTo which
uses paralellForEach.
This patch is to avoid using paralellForEach to call maybeCompress
to workaround the issue.
llvm-svn: 322041
Previously, in r320472, I moved the calculation of section offsets and sizes
for compressed debug sections into maybeCompress, which happens before
assignAddresses, so that the compression had the required information. However,
I failed to take account of relocations that patch such sections. This had two
effects:
1. A race condition existed when a debug section referred to a different debug
section (see PR35788).
2. References to symbols in non-debug sections would be patched incorrectly.
This is because the addresses of such symbols are not calculated until after
assignAddresses (this was a partial regression caused by r320472, but they
could still have been broken before, in the event that a custom layout was used
in a linker script).
assignAddresses does not need to know about the output section size of
non-allocatable sections, because they do not affect the value of Dot. This
means that there is no longer a reason not to support custom layout of
compressed debug sections, as far as I'm aware. These two points allow for
delaying when maybeCompress can be called, removing the need for the loop I
previously added to calculate the section size, and therefore the race
condition. Furthermore, by delaying, we fix the issues of relocations getting
incorrect symbol values, because they have now all been finalized.
llvm-svn: 321986
We normally want to ignore SHT_NOBITS sections when computing
offsets. The sh_offset of section itself seems to be irrelevant and
- If the section is in the middle of a PT_LOAD, it will make no
difference on the computed offset of the followup section.
- If it is in the end of a PT_LOAD, we want to avoid its alignment
changing the offset of the followup sections.
The issue is if it is at the start of the PT_LOAD. In that case we do
have to align it so that the following sections have congruent address
and offset module the page size. We were not handling this case.
This should fix freebsd kernel link.
llvm-svn: 321657
We normally avoid "switch (Config->EKind)", but in this case I think
it is worth it.
It is only executed when there is an error and it allows detemplating
a lot of code.
llvm-svn: 321404
Rui Ueyama