SHF_GROUP: Group Member Sections
----------------------------------
A section which is part of a group, and is to be retained or discarded with the
group as a whole, is identified by a new section header attribute: SHF_GROUP
This section is a member (perhaps the only one) of a group of sections, and the
linker should retain or discard all or none of the members. This section must be
referenced in a SHT_GROUP section. This attribute flag may be set in any section
header, and no other modification or indication is made in the grouped sections.
All additional information is contained in the associated SHT_GROUP section.
SHT_GROUP: Section Group Definition
-------------------------------------
Represents a group section.
The section group's sh_link field identifies a symbol table section, and its
sh_info field the index of a symbol in that section. The name of that symbol is
treated as the identifier of the section group.
More information: https://mentorembedded.github.io/cxx-abi/abi/prop-72-comdat.html
Added a lot of extensive tests, that tests functionality.
llvm-svn: 230195
When the GNU linker sees two input sections with the same name, and the name
starts with ".gnu.linkonce.", the linker will only keep one copy and discard the
other. Any section whose name starts with “.gnu.linkonce.” is a COMDAT section.
Some architectures like Hexagon use this section to store floating point constants,
that need be deduped.
This patch adds gnu.linkonce functionality to the ELFReader.
llvm-svn: 230194
There is code(added by me) in the YAMLReader which isn't correct when it handles references
for section groups. The test case was also checking for wrong outputs.
This fixes the bug and the testcase so that they check for proper outputs.
llvm-svn: 230190
This is mainly for back-compatibility with GNU ld.
Ideally --stats should be a general option in LinkingContext, providing
individual stats for every pass in the linking process.
In the GNU driver, a better wording could be used, but there's no need
to change it for now.
Differential Revision: D7657
Reviewed by: ruiu
llvm-svn: 230157
Now since the correct file path for atoms is available and not clobbered,
commit r222309 which was reverted previously can be added back.
No change in functionality.
llvm-svn: 230138
Looks like there's a threading issue in the COFF reader which makes
buildbot unstable. Probability of crash varies depending on the number
of input. If we are linking a big executalbe, LLD almost always crash.
This patch temporarily adds a lock to guard the reader so that LLD
doesn't crash. I'll investigate and fix the issue as soon as possible
because this patch has negative performance impact.
llvm-svn: 230086
The round-trip passes were introduced in r193300. The intention of
the change was to make sure that LLD is capable of reading end
writing such file formats.
But that turned out to be yet another over-designed stuff that had
been slowing down everyday development.
The passes ran after the core linker and before the writer. If you
had an additional piece of information that needs to be passed from
front-end to the writer, you had to invent a way to save the data to
YAML/Native. These passes forced us to do that even if that data
was not needed to be represented neither in an object file nor in
an executable/DSO. It doesn't make sense. We don't need these passes.
http://reviews.llvm.org/D7480
llvm-svn: 230069
LinkerScript AST nodes are never destroyed which means that their
std::vector members will never be destroyed.
Instead, allocate the operand list itself in the Parser's
BumpPtrAllocator. This ensures that the storage will be destroyed along
with the nodes when the Parser is destroyed.
llvm-svn: 229967
This is yet another edge case of base relocation for symbols. Absolute
symbols are in general not target of base relocation because absolute
atom is a way to point to a specific memory location. In r229816, I
removed entries for absolute atoms from the base relocation table
(so that they won't be fixed by the loader).
However, there was one exception -- ImageBase. ImageBase points to the
start address of the current image in memory. That needs to be fixed up
at load time. This patch is to treat the symbol in a special manner.
llvm-svn: 229961
Previously we wrongly emitted a base relocation entry for an absolute symbol.
That made the loader to rewrite some instruction operands with wrong values
only when a DLL is not loaded at the default address. That caused a
misterious crash of some executable.
Absolute symbols will of course never change value wherever the binary is
loaded to memory. We shouldn't emit base relocations for absolute symbols.
llvm-svn: 229816
When this test was written, no llvm tool could print out contents
of base relocation section. Now llvm-readobj is able to dump it in
a text format. Use that tool to make this test readable.
llvm-svn: 229814
Weak aliases defined using /alternatename command line option were getting
wrong RVAs in the final output because of wrong atom ordinal. Alias atoms
were assigned large ordinals than any other regular atoms because they were
instantiated after other atoms and just got new (larger) ordinals.
Atoms are sorted by its file and atom ordinals in the order pass. Alias
atoms were located after all other atoms in the same file.
An alias atom's ordinal needs to be smaller than its alias target but larger
than the atom appeared before the target -- so that the alias is located
between the two. Since an alias has no size, the alias target will be located
at the same location as the alias.
In this patch, I made a gap between two regular atoms so that we can put
aliases after instantiating them (without re-numbering existing atoms).
llvm-svn: 229762
atomContent's memory is freed at the end of the stack frame,
but it is referenced by the atom pushed into _definedAtoms.
Differential Revision: http://reviews.llvm.org/D7732
llvm-svn: 229749
The atoms may be processed in different orders on different systems
based on allocated addresses. This is a bit unfortunate as it would
be nice to have error messages emitted in order of file contents.
However we are emitting errors inside a parallel_for_each so even if
we stabilize the order of atom processing we would need to do some
further work in order to ensure that thread scheduling doesn't perturb
the order of errors. For now switch to using CHECK-DAG instead of CHECK.
llvm-svn: 229487
Summary:
Define an explicit type for arch specific reference kind and use it in switch statement to make the compiler emit warnings if some case is not cover.
It will help to catch such errors when we add new mach-o reference kind.
Reviewers: shankarke, kledzik
Reviewed By: shankarke
Subscribers: shankarke, aemerson, llvm-commits
Projects: #lld
Differential Revision: http://reviews.llvm.org/D7612
llvm-svn: 229246
Wrap functionality was using a std::set to record symbols that need to be
wrapped. This changes the implementation to use a StringSet instead.
No change in functionality.
llvm-svn: 229165
If the name field of a symbol table entry is all zero, it's interpreted
as it's pointing to the beginning of the string table. The first four
bytes of the string table is the size field, so dumpbin dumps that number
as an ASCIZ string.
This patch fills a dummy value to name field.
llvm-svn: 228971
Looks like there's a race condition around here that caused LLD to crash
on Windows. Currently we are parsing libraries specified by .drectve section
asynchronously, and something is wrong in that process. Disable the feature
for now to make buildbots happy.
llvm-svn: 228955
Use a wrapper function for symbol. Any undefined reference to symbol will be
resolved to "__wrap_symbol". Any undefined reference to "__real_symbol" will be
resolved to symbol.
This can be used to provide a wrapper for a system function. The wrapper
function should be called "__wrap_symbol". If it wishes to call the system
function, it should call "__real_symbol".
Here is a trivial example:
void * __wrap_malloc (size_t c)
{
printf ("malloc called with %zu\n", c);
return __real_malloc (c);
}
If you link other code with this file using --wrap malloc, then all calls
to "malloc" will call the function "__wrap_malloc" instead. The call to
"__real_malloc" in "__wrap_malloc" will call the real "malloc" function.
llvm-svn: 228906
This adds the LinkingContext parameter to the ELFReader. Previously the flags in
that were needed in the Context was passed to the ELFReader, this made it very
hard to access data structures in the LinkingContext when reading an ELF file.
This change makes the ELFReader more flexible so that required parameters can be
grabbed directly from the LinkingContext.
Future patches make use of the changes.
There is no change in functionality though.
llvm-svn: 228905
The dumpbin tool in the MSVC toolchain cannot handle an executable created
by LLD if the executable contains a long section name.
In PE/COFF, a section name is stored to a section table entry. Because the
section name field in the table is only 8 byte long, a name longer than
that is stored to the string table and the offset in the string table is
stored to the section table entry instead.
In order to look up a string from the string table, tools need to handle
the symbol table, because the string table is defined as it immediately
follows the symbol table.
And seems the dumpbin doesn't like zero-length symbol table.
This patch teaches LLD how to emit a dummy symbol table. The dummy table
has one dummy entry in it.
llvm-svn: 228900
When calling ARM code from Thumb and vice versa,
a veneer that switches instruction set should be generated.
Added veneer generation for ARM_JUMP24 ARM_THM_JUMP24 instructions.
Differential Revision: http://reviews.llvm.org/D7502
llvm-svn: 228680
We used to do like this instead of putting all command line processing
code within one gigantic switch statement. It is converted to a switch
in r188958, which introduced InputGraph.
In this patch I roll that change back. Now all "break"s are removed,
and the nesting is one level shallow.
llvm-svn: 228646
The values are already arranged in ascending order, and all tests still pass.
Removing the values as its confusing when new enumerations need to be added.
llvm-svn: 228381
After the total number of program headers are determined, virtual addresses
and file offsets need not be reassigned for sections whose virtual addresses and
fileoffsets remained the same.
This doesnot change any functionality.
llvm-svn: 228377
Use the environment variable "LLD_RUN_ROUNDTRIP_TEST" in the test that you want
to disable, as
RUN: env LLD_RUN_ROUNDTRIP_TEST= <run>
This was a patch that I made, but I find this a better way to accomplish what we
want to do.
llvm-svn: 228376
Only search library directories explicitly specified
on the command line. Library directories specified in linker
scripts (including linker scripts specified on the command
line) are ignored.
llvm-svn: 228375
Previously we only have File::path() to get the path name of a file.
If a file was a member of an archive file, path() returns a concatenated
string of the file name in the archive and the archive file name.
If we wanted to get a file name or an archive file name, we had to
parse that string. That's of course not good.
This patch adds new member functions, archivePath and memberPath, to File.
http://reviews.llvm.org/D7447
llvm-svn: 228352
The real user of the LayoutPass is now only Mach-O, so move that
pass out of the common directory to Mach-O directory.
"Core" architecture were using the LayoutPass. I modified that
to use a simple OrderPass. I think no one actually have authority
what feature should be in Core and what's not, but I believe the
LayoutPass is not very suitable for Core. Before more code starts
depending on the complex pass, it's better to remove that from
Core.
I could have simplified that pass because Mach-O is the only user
of the LayoutPass. For example, the second parameter of the
LayoutPass constructor can be converted from optional to mandatory.
I didn't do that in this patch to keep it simple. I'll do in a
followup patch.
http://reviews.llvm.org/D7311
llvm-svn: 228341
Previously, we incorrectly added the image base address to an absolute
symbol address (that calculation doesn't make any sense) if an
IMAGE_REL_I386_DIR32 relocation is applied to an absolute symbol.
This patch fixes the issue. With this fix, we can link Bochs using LLD.
(Choosing Bochs has no special meaining -- I just picked it up as a
test program and found it didn't work.) This also fixes one of the
issues we currently have to link Chromium using LLD.
llvm-svn: 228279
This may be a little bit inefficient than the original code
but that should be okay as this is not really in a performance
critical pass.
http://reviews.llvm.org/D7393
llvm-svn: 228077
INPUT directive is a variant of GROUP in the sense that that specifies
a list of input files. The only difference is whether the entire file
list is wrapped with a --start-group/--end-group or not.
http://reviews.llvm.org/D7390
llvm-svn: 228060
Currently, no one owns script::Parser buffers, but yet ELFLinkingContext gets
updated with StringRef pointers to data inside Parser buffers. Since this buffer
is locally owned inside GnuLdDriver::evalLinkerScript(), as soon as this
function finishes, all pointers in ELFLinkingContext that comes from linker
scripts get invalid. The problem is that we need someone to own linker scripts
data structures and, since ELFLinkingContext transports references to linker
scripts data, we can simply make it also own all linker scripts data.
Differential Revision: http://reviews.llvm.org/D7323
llvm-svn: 227975
Added relocations to perform function calls with and without passing arguments.
ARM-only, Thumb-only and mixed mode code generations are supported.
Only simple veneers (direct instruction modification) are supported as ARM-Thumb interwork.
Differential Revision: http://reviews.llvm.org/D7223
llvm-svn: 227961
This caused some tests to fail on FreeBSD, and Mac OS X.
Some std::sort() implementations will check for strict-weak-ordering
by comparing with the same element, or will compare an element to
itself for 1-element sequence. Take care of this case. Thanks to
chandlerc for explaning that to me.
Reviewed by: ruiu
llvm-svn: 227709
This is needed, among others by the FreeBSD kernel linker script.
Patch by Davide Italiano!
Reviewers: ruiu, rafaelauler
Differential Revision: http://reviews.llvm.org/D7220
llvm-svn: 227694
These fields were made protected in r193585. The aim of that change is to
expose these fields to SimpleFileWrapper. Because SimpleFileWrapper class
was removed in r227549, we can make them private.
llvm-svn: 227672
Previously we applied the LayoutPass to order atoms and then
apply elf::ArrayOrderPass to sort them again. The first pass is
basically supposed to sort atoms in the normal fashion (which
is to sort symbols in the same order as the input files).
The second pass sorts atoms in {init,fini}_array.<priority> by
priority.
The problem is that the LayoutPass is overkill. It analyzes
references between atoms to make a decision how to sort them.
It's slow, hard to understand, and above all, it doesn't seem
that we need its feature for ELF in the first place.
This patch remove the LayoutPass from ELF pass list. Now all
reordering is done in elf::OrderPass. That pass sorts atoms by
{init,fini}_array, and if they are not in the special section,
they are ordered as the same order as they appear in the command
line. The new code is far easier to understand, faster, and
still able to create valid executables.
Unlike the previous layout pass, elf::OrderPass doesn't count
any attributes of an atom (e.g. permissions) except its
position. It's OK because the writer takes care of them if we
have to.
This patch changes the order of final output, although that's
benign. Tests are updated.
http://reviews.llvm.org/D7278
llvm-svn: 227666
SimpleFileWrapper was a class to wrap an existing (possibly non-mutable)
file as a mutable file. We used instances of the class in RoundTrip*
passes, because the passes convert mutable files to non-mutable files,
and we needed to convert them back to mutable.
That feature can be implemented without defining a new class. Generally
speaking, if we can implement a feature without defining a class and
using only public interface of exsiting classes, that's preferred way
to do that. And this is the case.
llvm-svn: 227549
The LayoutPass is one of the slowest pass. This change is to skip
that pass. This change not only improve performance but also improve
maintainability of the code because the LayoutPass is pretty complex.
Previously we used the LayoutPass to sort all atoms in a specific way,
and reorder them again for PE/COFF in GroupedSectionPass.
I spent time on improving and fixing bugs in the LayoutPass (e.g.
r193029), but the pass is still hard to understand and hard to use.
It's better not to depend on that if we don't need. For PE/COFF, we
just wanted to sort atoms in the same order as the file order in the
command line.
The feature we used in the LayoutPass is now simplified to
compareByPosition function in OrderPass.cpp. The function is just 5
lines.
This patch changes the order of final output because it changes the
sort order a bit. The output is still correct, though.
llvm-svn: 227500
That kind of reference was used only in ELFFile, and the use of
that reference there didn't seem to make sense. All test still
pass (after adjusting symbol names) without that code. LLD is
still be able to link LLD and Clang. Looks like we just don't
need this.
http://reviews.llvm.org/D7189
llvm-svn: 227259
Misread buildbot's log.
Both gcc and clang compile this fine.
Original fix reason:
gcc allows template specializations only in the same namespace
where template has been declared.
llvm-svn: 227183
Symbols addressing Thumb code have zero bit set in st_value to distinguish them from ARM instructions.
This caused wrong atoms' forming because of offset of one byte brought in by that corrected st_value.
Fixed reading of st_value & st_value-related things in ARMELFFile while forming atoms.
Symbol table generation is also fixed for Thumb atoms.
Differential Revision: http://reviews.llvm.org/D7161
llvm-svn: 227174
Anonymous atoms created there were getting wrong atom ordinal.
LayoutAfter references take precedence over atom ordinals, so
the bug was not visible, though.
llvm-svn: 227168
* Removed cyclic dependency between lldPECOFF and lldDriver
* Added missing dependencies in unit tests
Differential Revision: http://reviews.llvm.org/D7185
llvm-svn: 227134
Time to link lld using lld improved from 5.7s to 5.4s on Windows.
It's not a significant improvement but not bad for one-line change.
This patch includes a bug fix for Parallel.h as the original code
uses operator< instead of a compare function there.
llvm-svn: 227132
This is initial patch to support MIPS64 object files linking.
The patch just makes some classes more generalized, and rejects
attempts to interlinking O32 and N64 ABI object files.
I try to reuse the current MIPS target related classes as much as
possible because O32 and N64 MIPS ABI are tightly related and share
almost the same set of relocations, GOT, flags etc.
llvm-svn: 227058
Shankar Easwaran