We would crash if a SHF_LINK_ORDER section pointed to a non
InputSection section. Since those sections are not merged in order,
SHF_LINK_ORDER is pretty meaningless and we can error on that case.
llvm-svn: 304327
This change converts the writing of the .ARM.exidx sentinel section to use
the InputSectionDescriptions instead of OutputSection::Sections this is in
preparation for the retirement of OutputSection::Sections.
Differential Revision: https://reviews.llvm.org/D33500
llvm-svn: 304289
This happens when attempting to link shared libraries using exceptions on
MIPS. It requires -z notext because clang generates R_MIPS_64 relocations
inside .eh_frame.
The crash happened because for EhInputSection the OutSec member is null.
Patch by Alexander Richardson!
llvm-svn: 304260
The .dynamic section of an ELF almost doesn't need to be written to with
the exception of the DT_DEBUG entry. For several reasons having a read
only .dynamic section would be useful. This change adds the -z keyword
"rodynamic" which forces .dynamic to be read-only. In this case DT_DEBUG
will not be emited.
Patch by Jake Ehrlich
Differential Revision: https://reviews.llvm.org/D33251
llvm-svn: 304024
I found this when builded llc binary using gcc 5.4.1 + LLD.
gcc produces duplicate entries in .debug_gnu_pubtypes section, ex:
UnifyFunctionExitNodes.cpp.o has:
0x0000ac07 EXTERNAL TYPE "std::success_type<void*>"
0x0000ac07 EXTERNAL TYPE "std::success_type<void*>"
clang produces single entry here:
0x0000d291 EXTERNAL TYPE "std::__success_type<void *>"
If we link output from gcc with LLD, that would produce excessive duplicate
entries in .gdb_index constant pool area. That does not seem affect gdb work,
but makes .gdb_index larger than it can be.
I also checked that gold filters out such duplicates too. Patch fixes it.
Differential revision: https://reviews.llvm.org/D32647
llvm-svn: 303975
https://sourceware.org/gdb/onlinedocs/gdb/Index-Section-Format.html says:
"A CU vector in the constant pool is a sequence of offset_type values.
The first value is the number of CU indices in the vector.
Each subsequent value is the index and symbol attributes of a CU in the CU list."
Previously we keeped 2 values until the end, what was useless.
Initially was a part of D32647, though it is possible to split out.
Patch do that.
Differential revision: https://reviews.llvm.org/D33551
llvm-svn: 303973
It is not clear why a synthetic section wants to use padding defined
in the linker script. The padding is for the space between sections.
It was also missing a test.
llvm-svn: 303812
This reduces how many times we have to map from OutputSection to
OutputSectionCommand. It is a required step to moving
clearOutputSections earlier.
In order to always use writeTo in OutputSectionCommand we have to call
fabricateDefaultCommands for -r links and move section compression
after it.
llvm-svn: 303784
GetSection is a template because write calls relocate.
relocate has two parts. The non alloc code really has to be a
template, as it is looking a raw input file data.
The alloc part is only a template because of getSize.
This patch folds the value of getSize early, detemplates
getRelocTargetVA and splits relocate into a templated non alloc case
and a regular function for the alloc case. This has the nice advantage
of making sure we collect all the information we need for relocations
before getting to InputSection::relocateNonAlloc.
Since we know got is alloc, it can just call the function directly and
avoid the template.
llvm-svn: 303355
SymbolTableBaseSection was introduced.
Detemplation of SymbolTableSection should allow to detemplate more things.
Differential revision: https://reviews.llvm.org/D33124
llvm-svn: 303150
We should only ever expect this function to return a regular
InputSection; I would not expect a function definition to be in a
MergeInputSection or EhInputSection. We were previously crashing
in writeTo if this function returned a section that was not an
InputSection because we do not set OutSec for such sections.
This can happen in practice if a function is defined in an empty
section which shares its offset-in-file with a MergeInputSection,
as in the provided test case.
A better fix for this bug would be to fix the
DWARFUnit::collectAddressRanges() interface to provide section
information (see D33183), but this at least fixes the crash.
Differential Revision: https://reviews.llvm.org/D33176
llvm-svn: 303089
This reverts changes introduced in r302414 "[ELF] - Set DF_STATIC_TLS flag for i386 target."
Because DF_STATIC_TLS does not look to be used by glibc or anything else.
llvm-svn: 302884
This is PR32437.
DF_STATIC_TLS
If set in a shared object or executable, this flag instructs the
dynamic linker to reject attempts to load this file dynamically.
It indicates that the shared object or executable contains code
using a static thread-local storage scheme. Implementations need
not support any form of thread-local storage.
Patch checks if IE/LE relocations were used to check if code uses
static model. If so it sets the DF_STATIC_TLS flag.
Differential revision: https://reviews.llvm.org/D32354
llvm-svn: 302414
Strip on OpenBSD does not correctly handle an empty .eh_frame section
and produces broken binaries in that case. Currently lld creates such
an empty .eh_frame section, despite the fact that the OpenBSD crtend.o
explicitly inserts a terminator. The Linux LSB "standard":
https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html#EHFRAME
explicitly says that
The .eh_frame section shall contain 1 or more Call Frame Information (CFI) records.
This diff includes a test that specifically tests the issue I'm seeing
on OpenBSD.
Patch by Mark Kettenis!
llvm-svn: 301931
For an option -foo-bar-baz, we have Config->FooBarBaz. Since -rpath is
-rpath and not -r-path, it should be Config->Rpath instead Config->RPath.
llvm-svn: 301759
We can just use the existing SoName member variable. It now initially
contains what was in DefaultSoName and is modified if the .so has an
actual soname.
llvm-svn: 301259
We generally want to use uint64_t instead of uintX_t if the 64-bit
type works for both 32-bit and 64-bit because it is simpler than
the variable-size type.
llvm-svn: 300293
Executable sections should not be padded with zero by default. On some
architectures, 0x00 is the start of a valid instruction sequence, so can confuse
disassembly between InputSections (and indeed the start of the next InputSection
in some situations). Further, in the case of misjumps into padding, padding may
start to be executed silently.
On x86, the "0xcc" byte represents the int3 trap instruction. It is a single
byte long so can serve well as padding. This change switches x86 (and x86_64) to
use this value for padding in executable sections, if no linker script directive
overrides it. It also puts the behaviour into place making it easy to change the
behaviour of other targets when desired. I do not know the relevant instruction
sequences for trap instructions on other targets however, so somebody should add
this separately.
Because the old behaviour simply wrote padding in the whole section before
overwriting most of it, this change also modifies the padding algorithm to write
padding only where needed. This in turn has caused a small behaviour change with
regards to what values are written via Fill commands in linker scripts, bringing
it into line with ld.bfd. The fill value is now written starting from the end of
the previous block, which means that it always starts from the first byte of the
fill, whereas the old behaviour meant that the padding sometimes started mid-way
through the fill value. See the test changes for more details.
Reviewed by: ruiu
Differential Revision: https://reviews.llvm.org/D30886
Bugzilla: http://bugs.llvm.org/show_bug.cgi?id=32227
llvm-svn: 299635
This patch changes GnuHashTableSection implementation
to avoid depend on uintX_t and other ELFT stuff, reducing amount of
changes for following patch(es).
Differential revision: https://reviews.llvm.org/D31184
llvm-svn: 298998
.gnu.hash happen to contain only 32-bit integers for 32-bit arch,
but the section contents are not uniform array members, so setting
entsize doesn't make much sense. This behavior seems to have been
blindly copied from GNU linkers.
llvm-svn: 298934
This is a shorthand for Config->Wordsize == 8. So this is not strictly
necessary but seems handy. "Is 64 bit?" is easier to read than "Is
wordsize 8 byte?"
llvm-svn: 298463
Patch moves Sections array to
InputFile (root class for input files).
That allows to detemplate GdbIndexSection.
Differential revision: https://reviews.llvm.org/D30976
llvm-svn: 298345
This continues detemplation process.
Detemplating MipsGotSection<ELFT> is helpfull because can
help to detemplate getRelocTargetVA. (one more change is required)
It opens road to detemplation of GotSection<ELFT> and probably
something else after that.
Differential revision: https://reviews.llvm.org/D31090
llvm-svn: 298272
Does not introduce anything new,
just performs detemplate, using methods we
already have.
Differential revision: https://reviews.llvm.org/D30935
llvm-svn: 298269
Rafael Espindola