- Dec 12, 2013
-
-
Rui Ueyama authored
/DLLEXPORT is a command line option to export a symbol. __declspec(dllexport) uses that to make the linker to export DLLExport'ed functions, by adding the option to .drectve section. This patch implements the parser of the command line option. llvm-svn: 197122
-
- Dec 11, 2013
-
-
Rui Ueyama authored
llvm-svn: 197085
-
Rui Ueyama authored
llvm-svn: 197039
-
Rui Ueyama authored
Before this patch, we had the following class hierarchy. Chunk -> AtomChunk -> SectionChunk -> GenericSectionChunk -> BaseRelocChunk -> HeaderChunk Chunk represented the generic concept of contiguous range in an output file. AtomChunk represented a chunk consists of atoms. That class hierarchy had many issues: 1) BaseRelocChunk does not really consist of atoms, so inheriting from AtomChunk was plainly wrong, and 2) the hierarchy is unecessarily too deep. This patch correct them. The new hierachy is shown below. Chunk -> SectionChunk -> AtomChunk -> BaseRelocChunk -> HeaderChunk In the new hierarchy, AtomChunk represents a chunk consists of atoms. Other types of sections (currently only BaseRelocChunk) should inherit directly from SectionChunk. llvm-svn: 197038
-
Rui Ueyama authored
Also removed unused field. llvm-svn: 197027
-
Rui Ueyama authored
No functionality change. llvm-svn: 197025
-
Rui Ueyama authored
Because sections no longer have trailing NULL bytes, size() and rawSize() now return the same value. llvm-svn: 197020
-
Rui Ueyama authored
llvm-svn: 197019
-
Rui Ueyama authored
llvm-svn: 197018
-
Rui Ueyama authored
This patch is to basically move the functionality to construct Data Directory from IdataPass to WriterPECOFF. Data Directory is a part of the PE/COFF header and contains the addresses of the import tables. We used to represent the link from Data Directory to the import tables as relocation references. The idea behind it is that, because relocation references are processed by the Writer, we wouldn't have to do anything special to fill the addresses of the import tables. I thought that the addresses would be set "automatically". But it turned out that that design made the pass and the writer rather complicated. In order to make relocation references between Data Directory to the import tables, these data structures needed to be represented as Atom. However, because Data Directory is not a section content but a part of the PE/COFF header, it did not fit well as an Atom. So we ended up having complicated code both in IdataPass and the writer. This patch simplifies it. One side effect of this patch is that we now have ".idata.a", ".idata.d" and "idata.t" sections for the import address table, the import directory table, and the import lookup table. The writer looks for the sections by name to find the start addresses of the sections. We probably should have a better way to find a specific atom from the core linking result, but currently using the section name seems to be the easiest way to do that. The Windows loader do not care about the import table's section layout. llvm-svn: 197016
-
Rui Ueyama authored
llvm-svn: 197009
-
Rui Ueyama authored
llvm-svn: 197008
-
Rui Ueyama authored
llvm-svn: 197007
-
Rui Ueyama authored
llvm-svn: 197006
-
Rui Ueyama authored
If section size is not multiple of 512, the writer added NULL bytes at the end of it to make it so. That is not required by the PE/COFF spec, and the MSVC's linker does not do that too. So we don't need to do that, too. llvm-svn: 197002
-
Rui Ueyama authored
llvm-svn: 196994
-
Rui Ueyama authored
The base class has a member function with the same name. We should avoid it being shadowed. llvm-svn: 196992
-
Rui Ueyama authored
llvm-svn: 196991
-
- Dec 10, 2013
-
-
Rui Ueyama authored
llvm-svn: 196898
-
Rui Ueyama authored
llvm-svn: 196897
-
Rui Ueyama authored
llvm-svn: 196896
-
Rui Ueyama authored
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
-
Rui Ueyama authored
llvm-svn: 196891
-
Rui Ueyama authored
... because they are used only in the function for relocations. llvm-svn: 196890
-
Rui Ueyama authored
llvm-svn: 196884
-
Rui Ueyama authored
llvm-svn: 196883
-
Rui Ueyama authored
Use of static is recommended by the style guide. llvm-svn: 196877
-
Rui Ueyama authored
llvm-svn: 196867
-
Rui Ueyama authored
These member functions are not overriden and not intended to be, so adding virtual does not make sense. llvm-svn: 196866
-
Rui Ueyama authored
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
-
- Dec 09, 2013
-
-
Joey Gouly authored
llvm-svn: 196770
-
Rui Ueyama authored
llvm-svn: 196767
-
Rui Ueyama authored
llvm-svn: 196762
-
Rui Ueyama authored
llvm-svn: 196756
-
Rui Ueyama authored
llvm-svn: 196754
-
Rui Ueyama authored
/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
-
Rui Ueyama authored
llvm-svn: 196741
-
- Dec 08, 2013
-
-
Rui Ueyama authored
llvm-svn: 196716
-
Rui Ueyama authored
Because compare() and its heper functions no longer have to be members of LayoutPass class, we can remove it from the class. No functionality change. llvm-svn: 196715
-
Rui Ueyama authored
The comparator used in the layout pass has many calls of map::find(). Because std::sort runs the comparator N*log2(N) times, the maps are looked up with the same key again and again. The map lookup is not a very fast operation. It made the pass slow. This patch eliminates the duplicate map lookups using decorate-sort-undecorate idiom. The pass used to take 1.1 seconds when linking LLD with LLD on Windows, but it now takes only 0.3 seconds. Overall performance gain in that case is from 6.1 seconds to 5.2 seconds. Differential Revision: http://llvm-reviews.chandlerc.com/D2358 llvm-svn: 196714
-