Imagine we have archive file with symbols foo and bar.
And script that do foo = 1.
In that case correct behavior is not to fetch symbols from archive but
create absolute symbol.
If we have script zed = foo then symbol foo will be fetched from archive.
Currently we have Opt.ReferencedSymbols list of symbols referenced
by script and create them undefined early. That allows archives fetching logic
to work. That is what LLD already do and it seems everything is fine here.
But during writing D37059 I had to add left side of assignments to
Opt.ReferencedSymbols list because wanted to stop optimizing out
these symbols when LTO is involved (LTO also uses this list).
And testcase from this patch would have fail if we would have it before.
Differential revision: https://reviews.llvm.org/D37208
llvm-svn: 312004
This is PR32429.
We did not mention -fPIC in error about producing dynamic relocation
in readonly segment before. Patch changes that.
Differential revision: https://reviews.llvm.org/D36874
llvm-svn: 312003
Various classes have `Symtab` member variables even though we have
lld::coff::Symtab variable because previous attempts to make COFF lld's
internal structure resemble to ELF's was incomplete. This patch finishes
that job by removing member variables.
llvm-svn: 311938
Summary:
ArgParser created an instance of COFFOptTable on stack to use it to
parser command line arguments. Parsed arguments were then returned from
the function as InputArgList. This was safe because InputArgList referred
only statically-allocated InfoTable.
That is not a safe assumption after https://reviews.llvm.org/D36782,
which changes the type of its internal table from ArrayRef to std::vector.
To make lld work with that patch, we need to keep an instance of
COFFOptTable at least as long as an InputArgList is alive. This patch
does that.
Reviewers: yamaguchi
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D37217
llvm-svn: 311930
Patch by Patricio Villalobos.
I discovered that lld for darwin is generating the wrong code for lazy
bindings in the __stub_helper section (at least for osx 10.12). This is
the way i can reproduce this problem, using this program:
#include <stdio.h>
int main(int argc, char **argv) {
printf("C: printf!\n");
puts("C: puts!\n");
return 0;
}
Then I link it using i have tested it in 3.9, 4.0 and 4.1 versions:
$ clang -c hello.c
$ lld -flavor darwin hello.o -o h1 -lc
When i execute the binary h1 the system gives me the following error:
C: printf!
dyld: lazy symbol binding failed:
BIND_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB
has segment 4 which is too large (0..3)
dyld: BIND_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB has segment 4 which is too
large (0..3)
Trace/BPT trap: 5
Investigating the code, it seems that the problem is that the asm code
generated in the file StubPass.cpp, specifically in the line 323,when it
adds, what it seems an arbitrary number (12) to the offset into the lazy
bind opcodes section, but it should be calculated depending on the
MachONormalizedFileBinaryWrite::lazyBindingInfo result.
I confirmed this bug by patching the code manually in the binary and
writing the right offset in the asm code (__stub_helper).
This patch fixes the content of the atom that contains the assembly code
when the offset is known.
Differential Revision: https://reviews.llvm.org/D35387
llvm-svn: 311734
linker script SECTION rules. This patch extends it to use a fully specified
file name as it appears in --trace output to match agains, i.e,
"<path>/<objname>.o" or "<path>/<libname>.a(<objname>.o)".
Differential Revision: https://reviews.llvm.org/D37031
llvm-svn: 311713
Currently LLD reads the R_MIPS_HI16's addends in the `computeMipsAddend`
function, the R_MIPS_LO16's addends in both `computeMipsAddend` and
`getImplicitAddend` functions. This patch moves reading all addends to
the `getImplicitAddend` function. As a side effect it fixes a "paired"
HI16/LO16 addend calculation if "LO16" part of a pair is not found.
llvm-svn: 311711
Before this patch, lld printed out something like
error: -O: number expected, but got
After this patch, it prints out the same error message like this:
error: -O: number expected, but got ''
Fixes https://bugs.llvm.org/show_bug.cgi?id=34311
llvm-svn: 311681
Currently, LLD checks whether there's enough space for headers by
checking if headers fit below the address of the first allocated
section. However, that's always thue if the binary doesn't start
at zero which means that LLD always emits a segment for headers,
even if no other sections belong to that segment.
This is a problem in cases when linker script is being used with a
non-zero start address when we don't want to make the headers visible
by not leaving enough space for them. This pattern is common in
embedded programming but doesn't work in LLD.
This patch changes the behavior of LLD in case when linker script
is being to match the behavior of BFD ld and gold, which is to only
place headers into a segment when they're covered by some output
section.
Differential Revision: https://reviews.llvm.org/D36256
llvm-svn: 311586
Previously up to 3 errors were reported at once,
with patch we always will report only one,
just like in other linker code.
Differential revision: https://reviews.llvm.org/D37015
llvm-svn: 311537
It was broken from begining, because visibility
attributes were not applied properly to
symbols before this patch.
Differential revision: https://reviews.llvm.org/D36966
llvm-svn: 311536
Code suggested by Rui Ueyama in PR34238 comments.
Previously LTO optimized away symbols referenced from linker script
because did not see that them are used from regular objects.
Patch adds such symbols as undefined earlier, before running LTO,
what sets IsUsedInRegularObj for them and fixes the issue.
Differential revision: https://reviews.llvm.org/D37009
llvm-svn: 311534
Patch by Rafael Espíndola.
This is PR34053.
The implementation is a bit of a hack, given the precise location where
IsPreemtible is set, it cannot be used from
SymbolTable::handleAnonymousVersion.
I could add another method to SymbolTable if you think that would be
better.
Differential Revision: https://reviews.llvm.org/D36499
llvm-svn: 311468
This is PR33097.
Previously when doing relocatable link, all IR symbols were absent
in result object file. Patch makes external symbols to be exported.
Differential revision: https://reviews.llvm.org/D36957
llvm-svn: 311431
Summary: Now that the llvm-mt manifest merging libraries are complete, we may use them to merge manifests instead of needing to shell out to mt.exe.
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D36255
llvm-svn: 311424
This adds support for dumping a summary of module symbols
and CodeView debug chunks. This option prints a table for
each module of all of the symbols that occurred in the module
and the number of times it occurred and total byte size. Then
at the end it prints the totals for the entire file.
Additionally, this patch adds the -jmc (just my code) option,
which suppresses modules which are from external libraries or
linker imports, so that you can focus only on the object files
and libraries that originate from your own source code.
llvm-svn: 311338
hexdump is not part of the GNU coreutils, and so is not required to be able to
build and test LLVM, according to the documentation. This change removes the
dependency on hexdump from a lit test.
Reviewers: grimar
Differential Revision: https://reviews.llvm.org/D36958
llvm-svn: 311335
With fix: explicitly specify ouput format for hexdump tool call.
Original commit message:
[ELF] - Do not forget to fill last bytes of PT_LOADs with trap instructions.
Previously last 4 bytes of executable loads
were not filled with trap instructions,
patch fixes this bug.
Differential revision: https://reviews.llvm.org/D36262
llvm-svn: 311315
Previously we would crash on samples from testcase,
because were trying to access zero pointer to output section.
Differential revision: https://reviews.llvm.org/D36145
llvm-svn: 311311
Previously last 4 bytes of executable loads
were not filled with trap instructions,
patch fixes this bug.
Differential revision: https://reviews.llvm.org/D36262
llvm-svn: 311310
We would previously crash on next script:
MEMORY { name : ORIGIN = .; }
Patch fixes that.
Differential revision: https://reviews.llvm.org/D36138
llvm-svn: 311073
We had a lock to guard BAlloc from being used concurrently, but that
is not very easy to understand. This patch replaces it with a
std::unique_ptr.
llvm-svn: 311056
Clang passes this options to linker. We should ignore them,
anyways they are always enabled by default atm.
Fixes https://bugs.llvm.org/show_bug.cgi?id=34200.
llvm-svn: 310995
When creating an import library from lld, the cases with
Name != ExtName shouldn't end up as a weak alias, but as a real
export of the new name, which is what actually is exported from
the DLL.
This restores the behaviour of renamed exports to what it was in
4.0.
Differential Revision: https://reviews.llvm.org/D36634
llvm-svn: 310992
Since SVN r303491 and r304573, LLD used the COFFImportLibrary
functions from LLVM. These only had two names, Name and ExtName,
which wasn't enough to convey all the details of stdcall functions.
Stdcall functions got the wrong symbol name in the import library
itself in r303491, which is why it was reverted in r304561. When
re-landed and fixed in r304573 (after adding a test in r304572),
the symbol name itself in the import library ended up right, but the
name type of the import library entry was wrong.
This had the effect that linking to the import library succeeded
(contrary to in r303491, where linking to such an import library
failed), but at runtime, the symbol wouldn't be found in the DLL
(since the caller linked to the stdcall decorated name).
Differential Revision: https://reviews.llvm.org/D36545
llvm-svn: 310989
I'm explicitly ignoring the warning by casting to void instead of
deleting the local assignment, because it's confusing to see a
function that fails when its return value evaluates to true.
But when you see that it's a std::error_code, it makes more sense.
llvm-svn: 310965
Previously, our algorithm to compute a build id involved hashing the
executable and storing that as the GUID in the CV Debug Record chunk,
and setting the age to 1.
This breaks down in one very obvious case: a user adds some newlines to
a file, rebuilds, but changes nothing else. This causes new line
information and new file checksums to get written to the PDB, meaning
that the debug info is different, but the generated code would be the
same, so we would write the same build over again with an age of 1.
Anyone using a symbol cache would have a problem now, because the
debugger would open the executable, look at the age and guid, find a
matching PDB in the symbol cache and then load it. It would never copy
the new PDB to the symbol cache.
This patch implements the canonical Windows algorithm for updating
a build id, which is to check the existing executable first, and
re-use an existing GUID while bumping the age if it already
exists.
Differential Revision: https://reviews.llvm.org/D36758
llvm-svn: 310961
GdbIndexSection doesn't need lazy finalization because when an instance
of the class is created, we already know all debug info sections.
We can initialize the instnace in the ctor.
llvm-svn: 310931
These are emitted for comm symbols in object files, when targeting
a GNU environment.
Alternatively, just ignore them since we already align CommonChunk
to the natural size of the content (up to 32 bytes). That would only
trade away the possibility to overalign small symbols, which doesn't
sound like something that might not need to be handled?
Differential Revision: https://reviews.llvm.org/D36304
llvm-svn: 310871
We don't have the right algorithm for copying S_UDT symbols
from object files to the globals stream, and having it wrong
is worse than not having it at all, since it breaks display
of local variables of UDT types (for example, "dv Foo" fails
in our current implementation, but succeeds if the S_UDT records
are omitted). Omit them until we fix the algorithm.
llvm-svn: 310867
This is relative to PR30720.
Previously we ignored all --plugin-opt arguments.
Patch adds support for them.
Patch does not add any new LTO options,
and just implements mapping from --plugin-opt to existent ones.
Differential revision: https://reviews.llvm.org/D36227
llvm-svn: 310826
The linker module contains a symbol of type S_COMPILE3 which
contains various information about the compiler and linker used
to create the PDB, such as the name of the linker, the target
machine, and the linker version. Interestingly, if we set the
version string to 0.0.0.0, then when trying to view local
variables WinDbg emits an error that private symbols are not
present. By setting this to a valid MSVC linker version string,
local variables can display.
As such, even though it is not representative of LLVM's version
information, we need this for compatibility.
llvm-svn: 310755
PDBs need to contain 1 module for each object file/compiland,
and a special one synthesized by the linker. This one contains
a symbol record for each output section in the executable with
its address information. This patch adds such symbols to the
linker module. Note that we also are supposed to add an
S_COFFGROUP symbol for what appears to be each input section that
contributes to each output section, but it's not entirely clear
how to generate these yet, so I'm leaving that for a separate
patch.
llvm-svn: 310754
Previously we were writing an empty globals stream. Windows
tools interpret this as "private symbols are not present in
this PDB", even when they are, so we need to fix this. Regardless,
without it we don't have information about global variables, so
we need to fix it anyway. This patch does that.
With this patch, the "lm" command in WinDbg correctly reports
that we have private symbols available, but the "dv" command
still refuses to display local variables.
Differential Revision: https://reviews.llvm.org/D36535
llvm-svn: 310743
This is PR33886,
previously we did not output common symbols to map,
patch fixes that.
Differential revision: https://reviews.llvm.org/D36466
llvm-svn: 310703
ResolvedReloc struct is always passed to a callback function and not
stored anywhere. That is, in effect, we use the struct to pack multiple
arguments to one argument, which doesn't make much sense. This patch
removes the struct and passes the members to the callback directly.
llvm-svn: 310620
Liveness is usually a notion of input sections, but this patch adds
"liveness" bit to common symbols because they don't belong to any
input section.
This patch is based on https://reviews.llvm.org/D36520
Differential Revision: https://reviews.llvm.org/D36546
llvm-svn: 310617
Summary: This small patch adds the support for ! operator in linker scripts.
Reviewers: ruiu, rafael
Reviewed By: ruiu
Subscribers: meadori, grimar, emaste, llvm-commits
Differential Revision: https://reviews.llvm.org/D36451
llvm-svn: 310607
This is probably a small optimization, but the main motivation is
having a way of fixing pr34053 that doesn't require a hash lookup in
isPreempitible.
llvm-svn: 310602
GC code contains following logic uncovered by tests:
for (StringRef S : Config->Undefined)
MarkSymbol(Symtab->find(S));
As far I can tell we never had test for that before,
patch fixes it.
Differential revision: https://reviews.llvm.org/D36519
llvm-svn: 310556
In the refactor to merge the publics and globals stream, a bug
was introduced that wrote the wrong value for one of the fields
of the PublicsStreamHeader. This caused debugging in WinDbg
to break.
We had no way of dumping any of these fields, so in addition to
fixing the bug I've added dumping support for them along with a
test that verifies the correct value is written.
llvm-svn: 310439
The publics stream and globals stream are very similar. They both
contain a list of hash buckets that refer into a single shared stream,
the symbol record stream. Because of the need for each builder to manage
both an independent hash stream as well as a single shared record
stream, making the two builders be independent entities is not the right
design. This patch merges them into a single class, of which only a
single instance is needed to create all 3 streams. PublicsStreamBuilder
and GlobalsStreamBuilder are now merged into the single GSIStreamBuilder
class, which writes all 3 streams at once.
Note that this patch does not contain any functionality change. So we're
still not yet writing any records to the globals stream. All we're doing
is making it so that when we do start writing records to the globals,
this refactor won't have to be part of that patch.
Differential Revision: https://reviews.llvm.org/D36489
llvm-svn: 310438
The compiler outputs PROC32_ID symbols into the object files
for functions, and these symbols have an embedded type index
which, when copied to the PDB, refer to the IPI stream. However,
the symbols themselves are also converted into regular symbols
(e.g. S_GPROC32_ID -> S_GPROC32), and type indices in the regular
symbol records refer to the TPI stream. So this patch applies
two fixes to function records.
1. It converts ID symbols to the proper non-ID record type.
2. After remapping the type index from the object file's index
space to the PDB file/IPI stream's index space, it then
remaps that index to the TPI stream's index space by.
Besides functions, during the remapping process we were also
discarding symbol record types which we did not recognize.
In particular, we were discarding S_BPREL32 records, which is
what MSVC uses to describe local variables on the stack. So
this patch fixes that as well by copying them to the PDB.
Differential Revision: https://reviews.llvm.org/D36426
llvm-svn: 310394
Emit these symbols as long as we're building in a static configuration,
even if we're emitting a dynamic symbol table. This is consistent with
both bfd and gold.
Ordinarily, the combination of -static and -export-dynamic wouldn't make
much sense. Unfortunately, cmake versions prior to 3.4 forcefully
injected -rdynamic [1], so it seems worthwhile to support.
[1] https://cmake.org/cmake/help/v3.4/policy/CMP0065.html
Differential Revision: https://reviews.llvm.org/D36350
llvm-svn: 310168
With this Symbol has the same size as before, but DefinedRegular goes
from 72 to 64 bytes.
I also find this a bit easier to read. There are fewer places
initializing File for example.
This has a small but measurable speed improvement on all tests (1%
max).
llvm-svn: 310142
Image section headers are stored in the DBI stream, but we
had no way to dump them. This patch adds dumping support,
along with some tests that LLD actually dumps them correctly.
Differential Revision: https://reviews.llvm.org/D36332
llvm-svn: 310107
D35945 introduces change when there is useless to check Error flag
in few places, but ErrorCount must be checked instead.
But then we probably can just check ErrorCount always. That should simplify
things. Patch do that.
Differential revision: https://reviews.llvm.org/D36266
llvm-svn: 310046
This is PR33889,
Patch adds support of combination of linkerscript and
-symbol-ordering-file option.
If no sorting commands are present in script inside section declaration
and no --sort-section option specified, code uses sorting from ordering
file if any exist.
Differential revision: https://reviews.llvm.org/D35843
llvm-svn: 310045
Following r309829, if a string table appears in an executable segment, the strings
will not be null terminated. This is a problem, for example, for the .dynstr
section when using -no-rosegment. The strings end up being terminated with 0xcc
because prior to this patch, LLD did not explicitly write the null terminators.
This change fixes that by always writing the null terminators.
Reviewers: rafael
Differential Revision: https://reviews.llvm.org/D36267
llvm-svn: 310042
Summary:
PDB section contributions are supposed to use output section indices and
offsets, not input section indices and offsets.
This allows the debugger to look up the index of the module that it
should look up in the modules stream for symbol information. With this
change, windbg can now find line tables, but it still cannot print local
variables.
Fixes PR34048
Reviewers: zturner
Subscribers: hiraditya, ruiu, llvm-commits
Differential Revision: https://reviews.llvm.org/D36285
llvm-svn: 309987
Following possible scripts triggered accessing to Target when it was not yet
initialized (was nullptr).
MEMORY { name : ORIGIN = DATA_SEGMENT_RELRO_END; }
MEMORY { name : ORIGIN = CONSTANT(COMMONPAGESIZE); }
Patch errors out instead.
Differential revision: https://reviews.llvm.org/D36140
llvm-svn: 309953
In order to get dbghelp to load our pdb, we have to fill in the
PointerToRawData field as well as the AddressOfRawData field. One is the
file offset and the other is the RVA.
llvm-svn: 309900
Reviewing another change I noticed that we use "getSymbols" to mean
different things in different files. Depending on the file it can
return
ArrayRef<StringRef>
ArrayRef<SymbolBody*>
ArrayRef<Symbol*>
ArrayRef<Elf_Sym>
With this change it always returns an ArrayRef<SymbolBody*>. The other
functions are renamed getELFsyms() and getSymbolNames().
Note that we cannot return ArrayRef<Symbol*> instead of
ArreyRef<SymbolBody*> because local symbols have a SymbolBody but not
a Symbol.
llvm-svn: 309840
When the data segment is the last segment, it is correct to leave
it unaligned. However, when the code segment is the last segment,
it should be aligned to the page boundary to avoid loading the
non-segment parts of the ELF file at the end of the file.
Differential Revision: https://reviews.llvm.org/D33630
llvm-svn: 309829
With fix for undefined weak symbols in executable.
Original commit message:
This is PR32112. Previously when we linked executable with
--unresolved-symbols=ignore-all and undefined symbols, like:
_start:
callq und@PLT
we did not create relocations, though it looks in that case
we should delegate handling of such symbols to runtime linker,
hence should emit them. Patch fixes that.
Differential revision: https://reviews.llvm.org/D35724
llvm-svn: 309796
We don't write any actual symbols to this stream yet, but for
now we just create the stream and hook it up to the appropriate
places and give it a valid header.
Differential Revision: https://reviews.llvm.org/D35290
llvm-svn: 309608
Before we were doing it with --export-dynamic. That seems incorrect.
The intention of --export-dynamic is to export symbols *defined* in
the executable.
llvm-svn: 309605
Previously we would crash when tried to ALIGN(0).
Patch uses value 1 instead in this case, that
looks to be consistent with GNU linkers
and reasonable and simple behavior itself.
Differential revision: https://reviews.llvm.org/D35942
llvm-svn: 309372
This is a bit of a hack, but it is *so* convenient.
Now that we create synthetic linker scripts when none is provided, we
always have to handle paired OutputSection and OutputsectionCommand and
keep a mapping from one to the other.
This patch simplifies things by merging them and creating what used to
be OutputSectionCommands really early.
llvm-svn: 309311
Summary:
MSVC link.exe records all external symbol names in the publics stream.
It provides similar functionality to an ELF .symtab.
Reviewers: zturner, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D35871
llvm-svn: 309303
That is slightly more convinent as allows to store pointer on
program header entry in a more safe way.
Change was used in 2 patches currently on review.
Differential revision: https://reviews.llvm.org/D35832
llvm-svn: 309253
This is PR32112. Previously when we linked executable with
--unresolved-symbols=ignore-all and undefined symbols, like:
_start:
callq und@PLT
we did not create relocations, though it looks in that case
we should delegate handling of such symbols to runtime linker,
hence should emit them. Patch fixes that.
Differential revision: https://reviews.llvm.org/D35724
llvm-svn: 309252
With this we only ask LTO to keep a C named section if there is a
__start_ or __end symbol.
This is not as strict as lld's --gc-sections, but is as good as we can
get without having a far more detailed ir summary.
llvm-svn: 309232
This patch fixes a small issue with respect to how memory region names
are parsed on output section descriptions. For example, consider:
.text : { *(.text) } > rom
That can also be written like:
.text : { *(.text) } >rom
The latter form is accepted by GNU LD and is fairly common.
Differential Revision: https://reviews.llvm.org/D35920
llvm-svn: 309191
Also handle overflow correctly in LDR/STR relocations. Even if the
offset range of a 8 byte LDR instruction is 15 bit (even if the immediate
itself is 12 bit) due to a 3 bit shift, only include up to 12 bits of offset
after doing the relocation, by limiting the range of the immediate by the
number of shifted bits.
Differential Revision: https://reviews.llvm.org/D35792
llvm-svn: 309175
Previously we handled this option implicitly, only
for infering unresolved symbols handling policy.
ld man says: "--noinhibit-exec Retain the executable
output file whenever it is still usable",
and we may want to handle other cases too.
Differential revision: https://reviews.llvm.org/D35793
llvm-svn: 309091
This is PR30422,
previously LLD did not render all option aliases in --help.
With this patch it will.
Differential revision: https://reviews.llvm.org/D35477
llvm-svn: 309089
The test used /manifestinput: without /manifest:embed, which isn't actually
supported. Just remove this part of the test for now; if it's important to
check this the llvm-readobj part should be extended to check this.
llvm-svn: 309002
Also emit an error if /manifestinput: is used without /manifest:embed.
Increases compatibility with link.exe
https://reviews.llvm.org/D35842
llvm-svn: 308998
Previously .init_array/.fini_array sections
were not unique and we had 3 .init_array sections +
3 .fini_array input sections passed to linker,
instead of 5 + 5.
Differential revision: https://reviews.llvm.org/D35552
llvm-svn: 308958
This is PR33714.
Previously for each input section offset of memory region
was incremented on a size of output section.
That resulted in a wrong error message saying about
overflow. Patch fixes that.
Differential revision: https://reviews.llvm.org/D35803
llvm-svn: 308955
The same adjustment is already done for the entry point in
Writer.cpp and for relocations that point to executable code
in Chunks.cpp.
Differential Revision: https://reviews.llvm.org/D35767
llvm-svn: 308953
We do this emitting a section for every function when LTO is used.
Fixes PR33888.
Differential Revision: https://reviews.llvm.org/D35809
llvm-svn: 308915
Eq helper allows to define `XXX` and `XXX=` options forms easily.
Patch adds testcases for few aliases.
Differential revision: https://reviews.llvm.org/D35619
llvm-svn: 308752
Also add the test cases for the addition and subtraction both for
the relative and absolute case.
Differential Revision: https://reviews.llvm.org/D35346
llvm-svn: 308692
We were not looking at Repl and so thinking there was no output
section associated with the merged symbol. Because of that it was
produced as absolute.
This was found by an internal round of testing.
llvm-svn: 308681
SHF_GROUP flag should have been removed when the control reaches here
because InputSectionBase turns the flag off. So this code should be
redundant.
llvm-svn: 308680
Summary:
If the linker is invoked with `--chroot /foo` and `/bar/baz.o`, it
tries to read the file from `/foo/bar/baz.o`. This feature is useful
when you are dealing with files created by the --reproduce option.
Reviewers: grimar
Subscribers: llvm-commits, emaste
Differential Revision: https://reviews.llvm.org/D35517
llvm-svn: 308646
Also extend the tests for IMAGE_REL_ARM64_PAGEOFFSET_12L to test
all 8/16/32/64 bit GPR and 8/16/32/64/128 SIMD/FP bit ldr/str variants,
and a ldr with an existing offset.
Differential revision: https://reviews.llvm.org/D35647
llvm-svn: 308631
Fix issues found in existing code, while reviewing other changes.
Change the data type of a variable to uint32_t, to avoid potential issues
with signedness in shifts.
Differential revision: https://reviews.llvm.org/D35646
llvm-svn: 308586
This fixes cases on ARM64 when importing from more than one DLL,
in case the imports from the first DLL ended up unaligned.
When fixing up a IMAGE_REL_ARM64_PAGEOFFSET_12L, which shifts the
offset by the load/store size, check that the shift doesn't discard
any bits. (This would also detect if the import address chunks were
unaligned.)
Differential revision: https://reviews.llvm.org/D35640
llvm-svn: 308585
With that in place we can use lld's own infrastructure for the low
level detail of dwarf parsing.
With this we don't decompress sections twice, we don't scan all
realocations and even with this simplistic implementation linking
clang with gdb index goes from 34.09 seconds to 20.80 seconds.
llvm-svn: 308544
In addition this includes a change to prefer symbols with a default
version @@ over unversioned symbols.
Original commit message:
[ELF] - Handle symbols with default version early.
This fixes last testcase provided in PR28414.
In short issue is next: when we had X@@Version symbol in object A,
we did not resolve it to X early. Then when in another object B
we had reference to undefined X, symbol X from archive was fetched.
Since both archive and object A contains another symbol Z, duplicate
symbol definition was triggered as a result.
Correct behavior is to use X@@Version from object A instead and do not fetch
any symbols from archive.
Differential revision: https://reviews.llvm.org/D35059
llvm-svn: 308492
This test is folded into implib-name. Don't bother with the racy test.
The use of %T results in left-overs from previous tests which write out
the same import library as this test.
llvm-svn: 308409
Improve the link conformance for the import name embedded into the
import library. This requires the associated change to the LLVM portion
for the DEF file parser. The import file generation embeds a different
name based on whether the driver is invoked as "link" or "lib".
Furthermore, the LIBRARY keyword in the DEF file influences the import
name. The behaviour can be summarised according to the following table:
| LIBRARY w/ ext | LIBRARY w/o ext | no LIBRARY
-----+----------------+---------------------+------------------
LINK | {value} | {value}.{.dll/.exe} | {output name}
LIB | {value} | {value}.dll | {output name}.dll
llvm-svn: 308407
Noticed while testing for an out of tree target. There are probably more tests that should be so marked.
I'm not sure who owns these tests so I've added a few names I recognise from the recent history.
With advice from probinson, ruiu, rafael and dramatically improved by davidb. Thank you all!
Differential Revision: https://reviews.llvm.org/D34685
llvm-svn: 308335
DWARF debug sections can also contain relocations against symbols in
discared segments. LLD should accept such relocations.
Differential Revision: https://reviews.llvm.org/D35526
llvm-svn: 308315
Assume that the LF_TYPESERVER2 record contains Windows-style paths. In
any case, 'sys::path::filename(Path, Style::windows)' will work on
Unix-style paths.
llvm-svn: 308241
Summary:
Object files compiled with /Zi emit type information into a type server
PDB. The .debug$S section will contain a single TypeServer2Record with
the absolute path and GUID of the type server. LLD needs to load the
type server PDB and merge all types and items it finds in it into the
destination PDB.
Depends on D35495
Reviewers: ruiu, inglorion
Subscribers: zturner, llvm-commits
Differential Revision: https://reviews.llvm.org/D35504
llvm-svn: 308235
Summary:
We were treating the GUIDs in TypeServer2Record as strings, and the
non-ASCII bytes in the GUID would not round-trip through YAML.
We already had the PDB_UniqueId type portably represent a Windows GUID,
but we need to hoist that up to the DebugInfo/CodeView library so that
we can use it in the TypeServer2Record as well as in PDB parsing code.
Reviewers: inglorion, amccarth
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D35495
llvm-svn: 308234
Rui Ueyama