Import Lookup Table in Import Directory Table has the same contents
as Hint/Name Table. Symbol names imported from DLLs are pointed by
both Import Directory Table and Hint/Name Table. We had duplicate
strings there.
This patch eliminates that duplication to make the table smaller.
This should reduce binary size by the sum of lengths of imported
symbols.
llvm-svn: 233128
Visual C++ shows the "right shift by too large amount" warning if
`MipsELFReference` is instantiated for 32-bit target and `Elf_Rel_Impl::getType`
method has `unsigned char` return type. We can freely suppress the warning in
that case because MIPS 32-bit ABI does not pack multiple relocation types into
the single field `r_type` and the `MipsELFReference::_tag` should be always
zero in that case.
No functional changes.
llvm-svn: 233088
N64 ABI relocation record r_info field in fact consists of five subfields:
* r_sym - symbol index
* r_ssym - special symbol
* r_type3 - third relocation type
* r_type2 - second relocation type
* r_type - first relocation type
Up to three these relocations applied one by one. The first relocation
uses an addendum from the relocation record. Each subsequent relocation
takes as its addend the result of the previous operation. Only the final
operation actually modifies the location relocated. The first relocation
uses as a reference symbol specified by the `r_sym` field. The third
relocation assumes NULL symbol.
The patch represents these data using LLD model and takes in account
additional relocation types during a relocation calculation.
Additional relocations do not introduce any new relations between two
atoms and just specify operations need to be done during a relocation
calculation. The first relocation type (`r_type`) stored in the
`Reference::_kindValue`. The rest of relocations and `r_ssym` value are
stored in the new `Reference::_tag` field "as-is". I decided to do not
"decode" these data on the core LLD level to prevent pollution of the
core LLD model by very target specific data.
Also I have to override writing of relocation records in the `RelocationTable`
class to convert MIPS N64 ABI relocation information from the `Reference`
class back to the ELF relocation record.
http://reviews.llvm.org/D8533
llvm-svn: 233057
The aforementioned relocation generate a GOT entry with a
R_X86_64_TPOFF64. The new relocation is processed at startup
time by the loader. lld didn't generate the outstanding relocation,
now it does. This bug was found while trying to link ls(1) on FreeBSD.
Simplified repro:
#include <stdio.h>
#include <wchar.h>
#include <wctype.h>
int
main(void)
{
wchar_t wc = 98;
if (!iswprint(wc))
printf("blah\n");
else
printf("foo\n");
return (0);
}
which incorrectly outputs "blah" when linked with lld before this patch.
llvm-svn: 233051
separately
This change reduce difference between the trunk and upcoming patch and
simplify the future code review.
No functional changes.
llvm-svn: 232919
This changes improves performance of lld, when self-hosting lld, when compared
with the bfd linker. BFD linker on average takes 8 seconds in elapsed time.
lld takes 3 seconds elapased time average. Without this change, lld takes ~5
seconds average. The runtime comparisons were done on a release build and
measured by running linking thrice.
lld self-host without the change
----------------------------------
real 0m3.196s
user 0m4.580s
sys 0m0.832s
lld self-host with lld
-----------------------
user 0m3.024s
user 0m3.252s
sys 0m0.796s
time taken to build lld with bfd
--------------------------------
real 0m8.419s
user 0m7.748s
sys 0m0.632s
llvm-svn: 232460
I knew I cut corners when I wrote this. Turned out that it is
actually slow when a file being read has many symbols. This patch
is to stop doing linear search and instead do map lookup.
llvm-svn: 232436
The `eh_frame_ptr` field in the `.eh_frame_hdr` section contains an address
of the `.eh_frame` section. Using an absolute 32-bit format for encoding
of this field does not work for 64-bit targets. It is better to use a
relative format because it covers both 32-bit and 64-bit cases. Sure
this work if a distance between `.eh_frame_hdr` and `.eh_frame` sections
is less than 4 Gb but it is a rather correct assumption.
http://reviews.llvm.org/D8352
llvm-svn: 232414
Puts symbols defined in linker script expressions in a runtime file that is
added as input to the resolver, making the input object files see symbols
defined in linker scripts.
http://reviews.llvm.org/D8263
llvm-svn: 232409
This commit implements the behaviour of the SECTIONS linker script directive,
used to not only define a custom mapping between input and output sections, but
also order input sections in the output file. To do this, we modify
DefaultLayout with hooks at important places that allow us to re-order input
sections according to a custom order. We also add a hook in SegmentChunk to
allow us to calculate linker script expressions while assigning virtual
addresses to the input sections that live in a segment.
Not all SECTIONS constructs are currently supported, but only the ones that do
not use special sort orders. It adds two LIT test as practical examples of
which sections directives are currently supported.
In terms of high-level changes, it creates a new class "script::Sema" that owns
all linker script ASTs and the logic for linker script semantics as well.
ELFLinkingContext owns a single copy of Sema, which will be used throughout
the object file writing process (to layout sections as proposed by the linker
script).
Other high-level change is that the writer no longer uses a "const" copy of
the linking context. This happens because linker script expressions must be
calculated *while* calculating final virtual addresses, which is a very late
step in object file writing. While calculating these expressions, we need to
update the linker script symbol table (inside the semantics object), and, thus,
we are "modifying our context" as we prepare to write the file.
http://reviews.llvm.org/D8157
llvm-svn: 232402
The gotSymbol need not be a global static variable. Apart from this reason, This
variable was creating an issue with self hosting lld, as there seems to be an
issue running global initializers, when initializing the guard for this static
variable.
Program received signal SIGTRAP, Trace/breakpoint trap.
llvm-svn: 232341
Handle resolution of symbols coming from linked object files lazily.
Add implementation of handling _GLOBAL_OFFSET_TABLE_ and __exidx_start/_end symbols for ARM platform.
Differential Revision: http://reviews.llvm.org/D8159
llvm-svn: 232261
The Segment Chunk had two functions one to append a section and one to append a
chunk. A section is a subclass of a chunk and clearly this can be merged into
one single function.
llvm-svn: 232249
GNU LD has an option named -T/--script which allows a user to specify
a linker script to be used [1]. LLD already accepts linker scripts
without this option, but the option is widely used. Therefore it is
best to support it in LLD as well.
[1] https://sourceware.org/binutils/docs/ld/Options.html#Options
llvm-svn: 232183
the spec required by std::sort and friends.
Ordering things this way also dramatically simplifies the code as
short-circuit ensures we can skip all of the negative tests.
I've left one FIXME where we're establishing a fairly arbitrary
ordering. Previously, the function compared all types as equal except
for the ones it explicitly handled, but it didn't delegate correctly to
the atomflags when doing so, and so it would fail to be a SWO. The two
possible fixes are to stop comparing the atom flags entirely, or to
establish some arbitrary ordering of the types.
Since it was pure luck which ordering of unequal types we ended up with
previously (the caller was std::sort, not std::stable_sort) I chose to
make the ordering explicit and guaranteed. This seems like the best
conservative approach as I suspect we would want to switch to
stable_sort otherwise in order to have deterministic output.
Differential Revision: http://reviews.llvm.org/D8266
llvm-svn: 231968
This patch implements parsing of the GNU ld MEMORY command [1].
The command and the memory block definitions are parsed as
specified (including the slightly strange "o" and "l" keywords).
Evaluation will be added at a later point in time.
[1] https://sourceware.org/binutils/docs-2.25/ld/MEMORY.html
llvm-svn: 231928
This will be replaced by a more generic class to handle
all the default symbols in an executable, e.g. __init_array.
Differential Revision: http://reviews.llvm.org/D8234
Reviewed by: shankare
llvm-svn: 231906
of the vector. For a vector 'v', '&v[v.size()]' isn't a valid way to
compute a pointer one-past-the-end of the vector. Instead, write the
loop in terms of iterators and save the beginning iterator. Once we have
that we can compute the beginning pointer from the beginning iterator,
and compute the distance which we should increment the beginning pointer
by subtracting the iterators.
What might be simpler would be to convert the function accepting a raw
pointer for begin and end to accept iterators or a range or some other
construct, but I wanted to keep this to a minimal bug-fix change.
This fixes a crash on any debug STL implementation which checks for
indexing out of bounds.
llvm-svn: 231765
The expression evaluation is needed when interpreting linker scripts, in order
to calculate the value for new symbols or to determine a new position to load
sections in memory. This commit extends Expression nodes from the linker script
AST with evaluation functions, and also contains a unit test.
http://reviews.llvm.org/D8156
llvm-svn: 231707
1. Move relocation addendum reading code to the MipsRelocationHandler
class to reduce code duplication.
2. Factor out the relocations calculation code into the separate
function to be ready to handle MIPS N64 ABI relocation chains.
No functional changes.
llvm-svn: 231641
We should not take in account a type of "source" symbol. Cross mode jump
adjustment is requred when target symbol and relocation belong to
different (regular/microMIPS) instruction sets.
llvm-svn: 231639
All readers except PE/COFF reader create layout-after edges to preserve
the original symbol order. PE/COFF uses layout-before edges as primary
edges for no reason.
This patch makes PE/COFF reader to create layout-after edges.
Resolver is updated to recognize reverse edges of layout-after edges
in the garbage collection pass.
Now we can retire layout-before edges. I don't do that in this patch
because if I do, I would have updated many tests to replace all
occurrrences of "layout-before" with "layout-after". So that's a TODO.
llvm-svn: 231615
If an output is large, its base relocation section can be also large.
For example, chrome.dll is almost 300 MB, and it has about 9 million
base relocations. Creating the section took 1.5 seconds on my machine.
This patch changes the way to create the section so that we can use
parallel_sort to group base relocations by high bits. This change
makes the linker almost 4% faster for the above test case on my machine.
If I replace parallel_sort with std::sort, performance remains the same,
so single thread performance should remain the same.
This has no functionality change. The output should be identical as
before.
llvm-svn: 231585
This patch reverts r231545 "PECOFF: Do not add extraneous symbols
to the dead strip root." CrWinClangLLD buildbot is currently broken.
Since I can't reproduce the issue locally, I'm reverting the most
relevant change.
llvm-svn: 231582
Atoms with fallback atoms are never be added to the symbol table.
However, we added such atoms to _undefines array. We had to call
isCoalescedAway to identify and skip them. We should just stop
adding them in the first place.
This seems to make the linker ~1% faster in my test case.
llvm-svn: 231552
If an undefined symbol is added to the symbol table by the previous
call of SymbolTable::add, SymbolTable::isDefined will always return
false for the same symbol.
llvm-svn: 231551
This is yet another optimization patch. Previously we called
SymbolTable::isDefined() and SymbolTable::findByName() from a very
frequently executed function. Because isDefined calls findByName,
findByName is called twice on each iteration.
findByName is not a cheap function. It computes a hash value for a
given symbol name. When linking C++ programs, it can be expensive
because of C++ mangled long symbols.
This patch reduces the number of call from 2 to 1. Performance
improvements by this patch was larger than I expected. Linking time
of chrome.dll gets almost 5% shorter.
llvm-svn: 231549
Previously we added all undefined symbols found in object files to
the dead strip root. This patch makes the linker to stop doing that.
Undefined symbols would be resolved anyway, so this patch doesn't
change the linker behavior. It should slightly improve performance
but it's really marginal. This is a cleanup.
llvm-svn: 231545
Previously applying 1 million relocations took about 2 seconds on my
Xeon 2.4GHz 8 core workstation. After this patch, it takes about 300
milliseconds. As a result, time to link chrome.dll becomes 23 seconds
to 21 seconds.
llvm-svn: 231454
In the resolver, we maintain a list of undefined symbols, and when we
visit an archive file, we check that file if undefined symbols can be
resolved using files in the archive. The archive file class provides
find() function to lookup a symbol.
Previously, we call find() for each undefined symbols. Archive files
may be visited multiple times if they are in a --start-group and
--end-group. If we visit a file M times and if we have N undefined
symbols, find() is called M*N times. I found that that is one of the
most significant bottlenecks in LLD when linking a large executable.
find() is not a very cheap operation because it looks up a hash table
for a given string. And a string, or a symbol name, can be pretty long
if you are dealing with C++ symbols.
We can eliminate the bottleneck.
Calling find() with the same symbol multiple times is a waste. If a
result of looking up a symbol is "not found", it stays "not found"
forever because the symbol simply doesn't exist in the archive.
Thus, we should call find() only for newly-added undefined symbols.
This optimization makes O(M*N) O(N).
In this patch, all undefined symbols are added to a vector. For each
archive/shared library file, we maintain a start position P. All
symbols [0, P) are already searched. [P, end of the vector) are not
searched yet. For each file, we scan the vector only once.
This patch changes the order in which undefined symbols are looked for.
Previously, we iterated over the result of _symbolTable.undefines().
Now we iterate over the new vector. This is a benign change but caused
differences in output if remaining undefines exist. This is why some
tests are updated.
The performance improvement of this patch seems sometimes significant.
Previously, linking chrome.dll on my workstation (Xeon 2.4GHz 8 cores)
took about 70 seconds. Now it takes (only?) 30 seconds!
http://reviews.llvm.org/D8091
llvm-svn: 231434
_reverseRef is a multimap from atoms to atoms. The map contains
reverse edges of "layout-before" and "group" edges for dead-stripping.
The type of the variable was DenseMap<Atom *, DenseSet<Atom *>>.
This patch changes that to std::unordered_multimap<Atom *, Atom *>.
A DenseMap with a value type of DenseSet was not fast. Inserting 900k
items to the map took about 1.6 seconds on my workstation.
unordered_multimap on the other hand took only 0.6 seconds.
Use of the map also got faster -- originally markLive took 1.3 seconds
in the same test case, and it now took 1.0 seconds. In total we shove
off 1.3 seconds out of 27 seconds in that test case.
llvm-svn: 231432
We maintain a map from symbols to archive files for the archive file
pre-loading. That map is created at the beginning of the resolve()
and is never updated. However, the input file list may be updated by
File::beforeLink(). This is a patch to update the map after beforeLink.
llvm-svn: 231395
I converted them to non-range-based loops in r226883 and r226893
because at that moment File::parse() may have side effects and
may update the vector that the reference returned from
LinkingContext::nodes().
Now File::parse() is free from side effects. We can use range-based
loops again.
llvm-svn: 231321
The last use of layout-after edge for PE/COFF was removed in r231290.
Now layout-after edges do nothing. We can stop adding them to the graph.
No functionality change intended.
llvm-svn: 231301
Merge::mergeByLargestSection is half-baked since it's defined
in terms of section size, there's no way to get the section size
of an atom.
Currently we work around the issue by traversing the layout edges
to both directions and calculate the sum of all atoms reachable.
I wrote that code but I knew it's hacky. It's even not guaranteed
to work. If you add layout edges before the core linking, it
miscalculates a size.
Also it's of course slow. It's basically a linked list traversal.
In this patch I added DefinedAtom::sectionSize so that we can use
that for mergeByLargestSection. I'm not very happy to add a new
field to DefinedAtom base class, but I think it's legitimate since
mergeByLargestSection is defined for section size, and the section
size is currently just missing.
http://reviews.llvm.org/D7966
llvm-svn: 231290
File objects are not really const in the resolver. We set ordinals to
them and call beforeLink hooks. Also, File's member functions marked
as const are not really const. ArchiveFile never returns the same
member file twice, so it remembers files returned before. find() has
side effects.
In order to deal with the inconsistencies, we sprinkled const_casts
and marked member varaibles as mutable.
This patch removes const from there to reflect the reality.
llvm-svn: 231212
std::promise and std::future in old version of libstdc++ are buggy.
I think that's the reason why LLD tests were flaky on Ubuntu 13
buildbots until we disabled file preloading.
In this patch, I implemented very simple future and used that in
FileArchive. Compared to std::promise and std::future, it lacks
many features, but should serve our purpose.
http://reviews.llvm.org/D8025
llvm-svn: 231153
Yet another chapter in the story. We're getting there, finally.
Note for the future: the tests for relocation have a lot of duplication
and probably can be unified in a single file. Let's reevaluate this once
the support will be complete (hopefully, soon).
llvm-svn: 231057
"virtual" was present at a wrong place. FileArchive is a subclass of
ArchiveLibraryFile, and a FileArchive can be deleted through a
pointer of ArchiveLibraryFile. We want to make the destructor of the
base class virtual.
llvm-svn: 231033
This reverts commit r228955. Previously files appear in a .drectve
section are parsed synchronously to avoid threading issues. I believe
it's now safe to do that asynchronously.
llvm-svn: 230905
This reverts commit r230086. I added a lock to guard FileCOFF::doParse(),
which killed parallel file parsing. Now the buildbots got back to green,
I believe the threading issue was resolved, so it's time to remove the
guard to see if it works with the buildbots.
llvm-svn: 230886
Previously we didn't call the hook on a file in an archive, which
let the PE/COFF port fail to link files in archives. It was a
simple mistake. Added a call to the hook and also added a test to
catch that error.
const_cast is an unfortunate hack. Files in the resolver are usually
const, but they are not actually const objects, since they are
mutated if either a file is taken from an archive (an archive file
does never return the same file twice) or the beforeLink hook is
called. Maybe we should just remove const from there -- because they
are not const.
llvm-svn: 230808
In doParse, we shouldn't do anything that has side effects. That function may be
called speculatively and possibly in parallel.
We called WinLinkDriver::parse from doParse to parse a command line in a .drectve
section. The parse function updates a linking context object, so it has many side
effects. It was not safe to call that function from doParse. beforeLink is a
function for a File object to do something that has side effects. Moving a call
of WinLinkDriver::parse to there.
llvm-svn: 230791
If no initial live symbols are set up, and deadStrip() == true,
the Resolver ends up reclaiming all the symbols that aren't absolute. This is wrong.
This patch fixes the issue by setting entrySymbolName() as live, and this allows
us to self-host lld when --gc-sections is enabled. There are still quite a few problems
with --gc-sections (test failures), so the option can't be enabled by default.
Differential Revision: D7926
Reviewed by: ruiu, shankarke
llvm-svn: 230737
It is observed that the function throws std::future_error on a few buildbots.
That cannot be easily reproducible on local machines. Kill the feature
temporarily to see if this is going to fix the buildbot issue.
llvm-svn: 230735
This reverts commit r230732.
sectionSize() in lib/Core/SymbolTable.cpp still depends on the layout-
after edges, so we couldn't remove them yet.
llvm-svn: 230734
Previously we needed to create atoms as a doubly-linked link, but it's
no longer needed. Also we don't use layout-after edges in PE/COFF.
Creating such edges is just waste.
llvm-svn: 230732
Nothing wrong with reinterpret_cast<llvm::support::ulittle32_t *>(loc),
but that's redundant and not great from readability point of view.
The new functions are wrappers for that kind of reinterpet_casts.
Surprisingly or unsurprisingly, there was no use of big endian read
and write. {read,write}{16,32,64}be have no user. But I think they
still worth to be there in the header for completeness.
http://reviews.llvm.org/D7927
llvm-svn: 230725
Previously we have a string -> string map to keep the weak alias
symbol mapping. Naturally we can't define more than one weak alias
with that data structure.
This patch is to allow multiple aliases for the same symbol by
changing the map type to string -> set of string map.
llvm-svn: 230702
This fixes a linker crash (found out while testing --gc-sections,
testcase provided by Rafael Avila de Espindola).
While this behaviour was found while testing ELF, it' not necessarily
ELF specific and this change is (apparently) harmless on all the
other drivers.
Differential Revision: D7823
Reviewed by: ruiu
llvm-svn: 230614
In LLD's model, symbol is a property of the node (atom) and not a property of
edge (reference). Prior to this patch, we stored the symbol in the reference.
From post-commit comments, it seemed better to create a map from the reference
to the symbol instead and use this mapping wherever desired.
Address comments from Ruiu/Simon Atanasyan.
llvm-svn: 230273
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
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
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
Simon Atanasyan