| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
Sections must start at page boundaries in memory, but they
can be aligned to sector boundaries (512-bytes) on disk.
We aligned them to 4096-byte boundaries even on disk, so we
wasted disk space a bit.
llvm-svn: 244691
|
|
|
|
|
|
|
| |
Handling the symbol this way is consistent with other symbols, such as
_tls_used. NFC.
llvm-svn: 244367
|
|
|
|
| |
llvm-svn: 244365
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has a few advantages
* Less C++ code (about 300 lines less).
* Less machine code (about 14 KB of text on a linux x86_64 build).
* It is more debugger friendly. Just set a breakpoint on the exit function and
you get the complete lld stack trace of when the error was found.
* It is a more robust API. The errors are handled early and we don't get a
std::error_code hot potato being passed around.
* In most cases the error function in a better position to print diagnostics
(it has more context).
llvm-svn: 244215
|
|
|
|
|
|
| |
On ARM, exception handler entries in .pdata section are 8 byte long.
llvm-svn: 244191
|
|
|
|
|
|
|
|
|
|
|
| |
Various parameters are passed implicitly using Config global variable
already. Output file path is no different from others, so there was no
special reason to handle that differnetly.
This patch changes the signature of writeResult(SymbolTable *, StringRef)
to writeResult(SymbolTable *).
llvm-svn: 244180
|
|
|
|
| |
llvm-svn: 244175
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I don't remember why I thought that only functions are subject
of garbage collection, but the comment here said so, which is
not correct. Moreover, the code just below the comment does not
do what the comment says -- it handles non-COMDAT, non-function
sections as GC root. As a result, it just handles non-COMDAT
sections as GC root.
This patch cleans that up by removing SectionChunk::isRoot and
use isCOMDAT instead.
llvm-svn: 243700
|
|
|
|
|
|
|
|
|
| |
We want to convince the NT loader not to map these sections into memory.
A good first step is to move them to the end of the executable.
Differential Revision: http://reviews.llvm.org/D11655
llvm-svn: 243680
|
|
|
|
| |
llvm-svn: 243588
|
|
|
|
|
|
|
|
| |
Windows ARM is the thumb ARM environment, and pointers to thumb code
needs to have its LSB set. When we apply relocations, we need to
adjust the LSB if it points to an executable section.
llvm-svn: 243560
|
|
|
|
|
|
|
|
|
|
|
| |
SECREL should sets the 32-bit offset of the target from the beginning
of *target's* output section. Previously, the offset from the beginning
of source's output section was used instead.
SECTION means the target section's index, and not the source section's
index. This patch fixes that issue too.
llvm-svn: 243535
|
|
|
|
| |
llvm-svn: 243532
|
|
|
|
| |
llvm-svn: 243495
|
|
|
|
|
|
|
|
| |
Previously, we ignore /merge option if /debug is specified
because I thought that was MSVC linker did. This was wrong.
/merge shouldn't be ignored even in debug mode.
llvm-svn: 243375
|
|
|
|
| |
llvm-svn: 243373
|
|
|
|
| |
llvm-svn: 243358
|
|
|
|
|
|
|
| |
Previously no __imp_ symbols nor dllimport thunk functions were
written to a symbol table.
llvm-svn: 243350
|
|
|
|
| |
llvm-svn: 243229
|
|
|
|
| |
llvm-svn: 243199
|
|
|
|
|
|
|
|
|
|
| |
On x64 and x86, we use only one base relocation type, so we handled
base relocations just as a list of RVAs. That doesn't work well for
ARM becuase we have to handle two types of base relocations on ARM.
This patch changes the type of base relocation from uint32_t to
{reltype, uint32_t} to make it easy to port this code to ARM.
llvm-svn: 243197
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An object file compatible with Safe SEH contains a .sxdata section.
The section contains a list of symbol table indices, each of which
is an exception handler function. A safe SEH-enabled executable
contains a list of exception handler RVAs. So, what the linker has
to do to support Safe SEH is basically to read the .sxdata section,
interpret the contents as a list of symbol indices, unique-fy and
sort their RVAs, and then emit that list to .rdata. This patch
implements that feature.
llvm-svn: 243182
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
__ImageBase is a special symbol whose value is the image base address.
Previously, we handled __ImageBase symbol as an absolute symbol.
Absolute symbols point to specific locations in memory and the locations
never change even if an image is base-relocated. That means that we
don't have base relocation entries for absolute symbols.
This is not a case for __ImageBase. If an image is base-relocated, its
base address changes, and __ImageBase needs to be shifted as well.
So we have to have base relocations for __ImageBase. That means that
__ImageBase is not really an absolute symbol but a different kind of
symbol.
In this patch, I introduced a new type of symbol -- DefinedRelative.
DefinedRelative is similar to DefinedAbsolute, but it has not a VA but RVA
and is a subject of base relocation. Currently only __ImageBase is of
the new symbol type.
llvm-svn: 243176
|
|
|
|
|
|
|
|
|
| |
Load Configuration field points to a structure containing information
for SEH. That data strucutre is not created by the linker but provided
by an external file. What we have to do is just to set __load_config_used
address to the header.
llvm-svn: 242427
|
|
|
|
|
|
|
|
| |
If /delayload option is given, we have to resolve __delayLoadHelper2
since the function is the dynamic loader to delay-load DLLs.
The function name is mangled in x86 as ___delayLoadHelper2@8.
llvm-svn: 242078
|
|
|
|
| |
llvm-svn: 242066
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we infer machine type at the very end of linking after
all symbols are resolved. That's actually too late because machine
type affects how we mangle symbols (whether or not we need to
add "_").
For example, /entry:foo adds "_foo" to the symbol table if x86 but
"foo" if x64.
This patch moves the code to infer machine type, so that machine
type is inferred based on input files given via the command line
(but not based on .directives files).
llvm-svn: 241843
|
|
|
|
|
|
|
| |
We can use the type and storage class from the symbol's original object
file to fill in the linked executable's symbol table.
llvm-svn: 241828
|
|
|
|
| |
llvm-svn: 241819
|
|
|
|
|
|
|
| |
With this patch, LLD is now able to correctly link a "hello world"
program written in assembly for 32-bit x86.
llvm-svn: 241771
|
|
|
|
|
|
| |
r241647 made Driver to infer machine type, so this code is not actually in use.
llvm-svn: 241720
|
|
|
|
|
|
|
|
|
|
| |
Providing a symbol table in the executable is quite useful when
debugging a fully-linked executable without having to reconstruct one
from DWARF.
Differential Revision: http://reviews.llvm.org/D11023
llvm-svn: 241689
|
|
|
|
| |
llvm-svn: 241657
|
|
|
|
| |
llvm-svn: 241477
|
|
|
|
|
|
|
|
|
| |
TLS table header field is supposed to have address and size of TLS table.
The linker doesn't have to understand what TLS table is. TLS table's name
is always "_tls_used", so if there's that symbol, the linker simply sets
that symbol's RVA to the header. The size of the TLS table is always 40 bytes.
llvm-svn: 241426
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the new design, mutation of Symbol pointers is the name resolution
operation. This patch makes them atomic pointers so that they can
be mutated by multiple threads safely. I'm going to use atomic
compare-exchange on these pointers.
dyn_cast<> doesn't recognize atomic pointers as pointers,
so we need to call load(). This is unfortunate, but in other places
automatic type conversion works fine.
llvm-svn: 241416
|
|
|
|
|
|
| |
/merge:.foo=.bar makes the linker to merge section .foo with section .bar.
llvm-svn: 241396
|
|
|
|
|
|
|
| |
GC root may have non-regular defined symbols, such as DefinedImportThunk,
so this cast<> was a wrong assumption.
llvm-svn: 241382
|
|
|
|
| |
llvm-svn: 241316
|
|
|
|
| |
llvm-svn: 241238
|
|
|
|
|
|
| |
The previous name was too long to my taste.
llvm-svn: 241215
|
|
|
|
|
|
|
|
|
| |
I think Undefined symbols are a bit more convenient than StringRefs
since SymbolBodies are handles for symbols. You can get resolved
symbols for undefined symbols just by calling getReplacmenet without
looking up the symbol table.
llvm-svn: 241214
|
|
|
|
|
|
|
|
|
|
| |
Occasionally we have to resolve an undefined symbol to its
mangled symbol. Previously, we did that on calling side of
findMangle by explicitly updating SymbolBody.
In this patch, mangled symbols are handled as weak aliases
for undefined symbols.
llvm-svn: 241213
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This flattens the entire liveness walk from a recursive mark approach to
a worklist approach. It also sinks the worklist management completely
out of the SectionChunk and into the Writer by exposing the ability to
iterato over children of a chunk and over the symbol bodies of relocated
symbols. I'm not 100% happy with the API names, so suggestions welcome
there.
This allows us to use a single worklist for the entire recursive walk
and would also be a natural place to take advantage of parallelism at
some future point.
With this, we completely inline away the GC walk into the
Writer::markLive function and it makes it very easy to profile what is
slow. Currently, time is being wasted checking whether a Chunk isa
SectionChunk (it essentially always is), finding (or skipping)
a replacement for a symbol, and chasing pointers between symbols and
their chunks. There are a bunch of things we can do to fix this, and its
easier to do them after this change IMO.
This change alone saves 1-2% of the time for my self-link of lld.exe
(which I'm running and benchmarking on Linux ironically).
Perhaps more notably, we'll no longer blow out the stack for large
links. =]
Just as an FYI, at this point, I/O is starting to really dominate the
profile. Well over 10% of the time appears to be inside the kernel doing
page table silliness. I think a decent chunk of this can be nuked as
well, but it's a little odd as cross-linking in this way isn't really
the primary goal here.
Differential Revision: http://reviews.llvm.org/D10790
llvm-svn: 240995
|
|
|
|
|
|
|
| |
This option is sometimes used to create a resource-only DLL that
doesn't need any initialization.
llvm-svn: 240915
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were a few issues with the previous delay-import tables.
- "Attribute" field should have been 1 instead of 0.
(I don't know the meaning of this field, though.)
- LEA and CALL operands had wrong addresses.
- Address tables are in .didat (which is read-only).
They should have been in .data.
llvm-svn: 240837
|
|
|
|
|
|
|
|
|
| |
I split them in r240319 because I thought they are different enough
that we should treat them as different types. It turned out that
that was not a good idea. They are so similar that we ended up having
many duplicate code.
llvm-svn: 240706
|
|
|
|
| |
llvm-svn: 240682
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Only SectionChunk can be dead-stripped. Previously,
all types of chunks implemented these functions,
but their functions were blank.
Likewise, only DefinedRegular and DefinedCOMDAT symbols
can be dead-stripped. markLive() function was implemented
for other symbol types, but they were blank.
I started thinking that the change I made in r240319 was
a mistake. I separated DefinedCOMDAT from DefinedRegular
because I thought that would make the code cleaner, but now
we want to handle them as the same type here. Maybe we
should roll it back.
This change should improve readability a bit as this removes
some dubious uses of reinterpret_cast. Previously, we
assumed that all COMDAT chunks are actually SectionChunks,
which was not very obvious.
llvm-svn: 240675
|
|
|
|
|
|
|
|
|
|
|
| |
The change I made in r240620 was not correct. If a symbol foo is
defined, and if you use __imp_foo, __imp_foo symbol is automatically
defined as a pointer (not just an alias) to foo.
Now that we need to create a chunk for automatically-created symbols.
I defined LocalImportChunk class for them.
llvm-svn: 240622
|