| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 196991
|
|
|
|
| |
llvm-svn: 196898
|
|
|
|
| |
llvm-svn: 196897
|
|
|
|
| |
llvm-svn: 196896
|
|
|
|
|
|
|
| |
Code to create COFF section header was scattered across many member functions
of SectionChunk. Consolidate it to a member function of SectionHeaderTableChunk.
llvm-svn: 196895
|
|
|
|
| |
llvm-svn: 196891
|
|
|
|
|
|
| |
... because they are used only in the function for relocations.
llvm-svn: 196890
|
|
|
|
| |
llvm-svn: 196884
|
|
|
|
|
|
| |
Use of static is recommended by the style guide.
llvm-svn: 196877
|
|
|
|
| |
llvm-svn: 196867
|
|
|
|
|
|
|
| |
These member functions are not overriden and not intended to be, so adding
virtual does not make sense.
llvm-svn: 196866
|
|
|
|
|
|
|
| |
This reverts commit r196475 because it made the build to fail with
GCC 4.7/4.8/4.9. Reported by Mikael Lyngvig.
llvm-svn: 196853
|
|
|
|
| |
llvm-svn: 196767
|
|
|
|
| |
llvm-svn: 196762
|
|
|
|
| |
llvm-svn: 196754
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
/ALTERNATENAME is a rarely-used, undocumented command line option that is
needed to link LLD for release build. It seems that the option is for defining
an weak alias; /alternatename:foo=bar defines weak symbol "foo" for "bar".
If "foo" is defined in an input file, it'll be linked normally and the command
line option will have no effect. If it's not defined, "foo" will be handled
as an alias for "bar".
This patch implements the parser for the option. The actual weak alias handling
will be implemented in a separate patch.
llvm-svn: 196743
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GroupedSectionsPass was a complicated pass. That pass's job was to reorder
atoms by section name, so that the atoms with the same section prefix will be
emitted consecutively to the executable. The pass added layout edges to atoms,
and let the layout pass to actually reorder them.
This patch simplifies the design by making GroupedSectionPass to directly
reorder atoms, rather than adding layout edges. This resembles ELF's
ArrayOrderPass.
This patch improves the performance of LLD; it used to take 7.1 seconds to
link LLD with LLD on my Macbook Pro, but it now takes 6.1 seconds.
llvm-svn: 196628
|
|
|
|
| |
llvm-svn: 196564
|
|
|
|
| |
llvm-svn: 196563
|
|
|
|
|
|
|
| |
Because ArrayRef has implicit conversion from C arrays, we don't need
makeArrayRef.
llvm-svn: 196475
|
|
|
|
| |
llvm-svn: 196465
|
|
|
|
|
|
|
|
| |
Emitting idata atoms to their own section would make debugging easier.
The Windows loader do not really care about whether the DLL import table is
in .rdata or its own .idata section, so there is no change in functionality.
llvm-svn: 196458
|
|
|
|
| |
llvm-svn: 196366
|
|
|
|
| |
llvm-svn: 196332
|
|
|
|
|
|
| |
These relocations are used in .debug section.
llvm-svn: 196262
|
|
|
|
| |
llvm-svn: 196185
|
|
|
|
|
|
|
| |
This reverts commit r195852 because LLD seems to create broken executables
with that patch when compiled with MSVC 2013.
llvm-svn: 196078
|
|
|
|
| |
llvm-svn: 196056
|
|
|
|
| |
llvm-svn: 196054
|
|
|
|
|
|
| |
No change in functionality.
llvm-svn: 196053
|
|
|
|
|
|
|
|
| |
This is a patch to let the PECOFF writer to use the information passed
by the parser for /section option. The implementation of /section should
now be complete.
llvm-svn: 195893
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
/MERGE option is a bit complicated for many reasons. Firstly, it takes both
positive and negative arguments. That means we have to have one of three
distinctive values (set, clear or unchange) for each permission bit. In this
patch we represent the three values using two bitmasks.
Secondly, the permissions specified by the parameter is bitwise or-ed with the
default permissions of a section. There is an exception for that rule; if one
of READ, WRITE or EXECUTE bit is specified, unspecified bits need to be
cleared. (So if you specify only WRITE for example, the resulting section will
not have WRITE nor EXECUTE bits.)
Lastly, multiple /merge options are allowed.
llvm-svn: 195882
|
|
|
|
|
|
|
| |
/MERGE:foo=bar command line option merges section foo to section bar. If
section bar does not exist, foo is just renamed as bar.
llvm-svn: 195856
|
|
|
|
| |
llvm-svn: 195855
|
|
|
|
|
|
|
| |
Atom ordinals are the indeces in a file. Currently the PECOFF reader assigns
ordinals for each section, so it's (incorrectly) assigning duplicate ordinals.
llvm-svn: 195852
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of having multiple SectionChunks for each section (.text, .data,
.rdata and .bss), we could have one chunk writer that can emit any sections.
This patch does that -- removing all section-sepcific chunk writers and
replace them with one "generic" writer.
This change should simplify the code because it eliminates similar-but-
slightly-different classes.
It also fixes an issue in the previous design. Before this patch, we could
emit only limited set of sections (i.e. .text, .data, .rdata and .bss). With
this patch, we can emit any sections.
llvm-svn: 195797
|
|
|
|
|
|
| |
This reverts accidental commit r195794.
llvm-svn: 195795
|
|
|
|
| |
llvm-svn: 195794
|
|
|
|
|
|
|
|
| |
According to the PE/COFF spec, a section with IMAGE_SCN_LNK_INFO should only
appear in an object file, and not allowed in an executable. So I believe
treating it as the same way as IMAGE_SCN_LNK_INFO is the right thing.
llvm-svn: 195692
|
|
|
|
|
|
|
| |
In order not to overrun a StringRef and copy the trailing garbage, we need to
set the maximum length to be copied by strncpy.
llvm-svn: 195688
|
|
|
|
| |
llvm-svn: 195618
|
|
|
|
|
|
|
|
|
| |
This patch won't change the output because the layout of linker internal
atoms is forced by layout-{before,after} references. Ordinals of the linker
internal atoms are not currently used. (That's why it's working even if there
are atoms having the same ordinals.)
llvm-svn: 195610
|
|
|
|
|
|
| |
Comment from Rui Ueyema.
llvm-svn: 195598
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change the attribute from sectionBasedOnContent to sectionCustomRequired
because its the right attribute for atoms read from COFF files to have.
COFF atoms should basically be emitted to the section having the same name
as input. Permissions/attributes should not affect that.
There's no functionality change because the writer doesn't yet use the
section name. The writer will be modified in a following patch, so that atoms
are written to its customSectionName()'s section.
llvm-svn: 195595
|
|
|
|
|
|
|
| |
Looks like -L paths are not positional. They need to be added to a list of
search paths and those needs to be searched when lld looks for a library.
llvm-svn: 195594
|
|
|
|
| |
llvm-svn: 195593
|
|
|
|
|
|
|
|
| |
If /subsystem option is not specified, the linker needs to infer it from the
entry point function. If "main" or "wmain" is defined, it's a console
application. If "WinMain" or "wWinMain" is defined, it's a GUI application.
llvm-svn: 195592
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds LinkerScript support by creating a type Script which is of type
FileNode in the InputGraph. Once the LinkerScript Parser converts the
LinkerScript into a sequence of command, the commands are handled by the
equivalent LinkerScript node for the current Flavor/Target. For ELF, a
ELFGNULdScript gets created which converts the commands to ELF nodes and ELF
control nodes(ELFGroup for handling Group nodes).
Since the Inputfile type has to be determined in the Driver, the Driver needs
to determine the complete path of the file that needs to be processed by the
Linker. Due to this, few tests have been removed since the Driver uses paths
that doesnot exist.
llvm-svn: 195583
|
|
|
|
| |
llvm-svn: 195284
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NativeReferenceIvarsV1 cannot handle more than 65535 relocation targets
because its field to point to the target table is of type uint16_t. Because
of that limitation, the LLD couldn't link a file containing more than 65535
relocations. 65535 is not a big number - the LLD couldn't even link itself
with V1.
This patch solves the issue by adding NativeReferenceIvarsV2 support. The
new structure has more bits for the target table, so it can handle a large
number of relocatinos.
V2 structure is larger than V1. In order to prevent file bloating, V2 format
is used only when the resulting file cannot be represented in V1 format. The
writer and the reader support both V1 and V2 formats.
Differential Revision: http://llvm-reviews.chandlerc.com/D2217
llvm-svn: 195270
|