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
Summary:
Instead of wiring these through the CVTypeVisitor interface, clients
should inspect the CVTypeArray before visiting it and potentially load
up the type server's TPI stream if they need it.
No tests relied on this functionality because LLD was the only client.
Reviewers: ruiu
Subscribers: mgorny, hiraditya, zturner, llvm-commits
Differential Revision: https://reviews.llvm.org/D35394
llvm-svn: 308212
The comment at the top of compareByFilePosition indicates that it relies
on stable_sort to preserve the order of synthetic sections. We were
using sort instead of stable_sort, however, leading to incorrect
synthetic section ordering.
Differential Revision: https://reviews.llvm.org/D35473
llvm-svn: 308207
In preparation for range extension thunks introduce a function that will
check whether a branch identified by a relocation type at a source address
can reach a destination.
For targets where range extension thunks are not supported the function will
return true as it is not expected that branches are out of range. An
implementation has been provided for ARM.
Differential Revision: https://reviews.llvm.org/D34690
llvm-svn: 308188
This is PR33766.
-F name
--filter=name
When creating an ELF shared object, set the internal DT_FILTER field to the specified name. This tells the dynamic linker that the symbol table of the shared object which is being created should be used as a filter on the symbol table of the shared object name.
If you later link a program against this filter object, then, when you run the program, the dynamic linker will see the DT_FILTER field. The dynamic linker will resolve symbols according to the symbol table of the filter object as usual, but it will actually link to the definitions found in the shared object name. Thus the filter object can be used to select a subset of the symbols provided by the object name.
(https://linux.die.net/man/1/ld).
Shared Objects as Filters:
https://docs.oracle.com/cd/E19683-01/817-3677/chapter4-31738/index.html
Differential revision: https://reviews.llvm.org/D35352
llvm-svn: 308167
Previously we used precompiled objects in gdb-index.s and
debug-gnu-pubnames.s testcases. We can avoid that.
Differential revision: https://reviews.llvm.org/D35360
llvm-svn: 308005
In filling the .got sections, InputSection::OutSecOff was added twice
when finding the position to apply a relocation: first time in
InputSection::writeTo() and then in SectionBase::getOffset().
Differential revision: https://reviews.llvm.org/D34232
llvm-svn: 308003
The /appcontainer flag was added in r299728, and the lib.exe dependency
for creating import libraries was removed in r275242. Update the docs
accordingly.
The PDB support also needs updating, but I'll leave that for someone
who's more familiar with the current status (probably rnk).
llvm-svn: 307998
This was previously erroring out if one of the dead symbols was a
TLS symbol and we were able to discard all TLS sections.
Differential Revision: https://reviews.llvm.org/D35397
llvm-svn: 307984
PT_TLS is a type of program header, so we wouldn't expect to see
one in an object file. This error should probably be referring to
the fact that we didn't see a section with the flag SHF_TLS, which
would normally cause us to create a PT_TLS program header.
Differential Revision: https://reviews.llvm.org/D35395
llvm-svn: 307983
Summary:
We've accumulated about five or so data structures that are widely
referenced:
- PDBBuilder
- Type table
- Id table
- PDB string table
- Type server handler
I'm about to rewrite type server handling, and I need a new class in LLD
where I can put its state. By creating a new PDBLinker class, I hope to
put it there next.
Reviewers: ruiu
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35392
llvm-svn: 307979
Functions declared in Strings.h should provide generic string operations
for the linker, but some of them are too specific to some features. This
patch moves them to the location where they are used.
llvm-svn: 307949
Summary:
This would have caught the invalid object file I used in my test case in
r307726. The OOB was only caught by ASan later, which is slow and
doesn't work on some platforms. LLD should do some basic input
validation itself. This check isn't perfect, so relocations can reach
OOB by up to seven bytes, but it's better than what we had and probably
cheap.
Reviewers: ruiu
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35371
llvm-svn: 307948
Summary:
This fixes type indices for SDK or CRT static archives. Previously we'd
try to look next to the archive object file path, which would not exist
on the local machine.
Also error out if we can't resolve a type server record. Hypothetically
we can recover from this error by discarding debug info for this object,
but that is not yet implemented.
Reviewers: ruiu, amccarth
Subscribers: aprantl, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D35369
llvm-svn: 307946
I have a patch to let DwarfContext defer to lld for getting section
contents and relocations.
That is a pretty big performance improvement.
This is just a refactoring to make that easier to do.
This change makes the *creation* of gdb index a dedicated step and
makes that templated. That is so that we can uses Elf_Rel in the code.
llvm-svn: 307867
Patch removes restriction about moving location counter
backwards outside of output sections declarations.
That may be useful for some apps relying on such scripts,
known example is linux kernel.
Differential revision: https://reviews.llvm.org/D34977
llvm-svn: 307794
This fixes PR33712.
Imagine following script and code:
VER1 { global: foo; local: *; };
VER2 { global: foo; };
.global bar
bar:
.symver bar, foo@VER1
.global zed
zed:
.symver zed, foo@@VER2
We add foo@@VER2 as foo to symbol table, because have to resolve references to
foo for default symbols.
Later we are trying to assign symbol versions from script. For that we are searching for 'foo'
again. Here it is placed under VER1 and VER2 at the same time, we find it twice and trying to
set version again both times, hence LLD shows a warning.
Though sample code is correct: we have 2 different versions of foo.
Patch gives a symbol version extracted from name a priority over version set by script.
Differential revision: https://reviews.llvm.org/D35207
llvm-svn: 307792
When version script was used, binding opf undefined weak symbols sometimes
was calculated as STB_LOCAL, making them non-preemtible what
broke correct relocations handling logic for them.
Fixes PR33738.
Differential revision: https://reviews.llvm.org/D35263
llvm-svn: 307767
Revert "[PDB] Tweak bad type index error handling"
check-lld with asan detects use-after-poison.
This reverts commits r307733 and r307726.
llvm-svn: 307752
Translate invalid type indices to a sentinel value instead of skipping
the record. Skipping records isn't a good recovery method, because we
can skip a scope open or close record, which will confuse the scope
management code.
We currently have lots of invalid type indices on Microsoft-provided
standard libraries, because the LF_TYPESERVER2 records contain absolute
paths that are only valid on their build servers. Our type server
handlers need to look at other things (GUIDs) to find these type server
PDBs.
llvm-svn: 307726
It was intially implemented in D19517 but then broken.
Patch fixes PR33707, testcase is based on PR's case.
Differential revision: https://reviews.llvm.org/D35119
llvm-svn: 307652
r307367 via D34345 split out the temporary address state used within
processCommands() and assignAddresses(). Due to the way that getSymbolValue
is used by the ScriptParser there is no way of giving the current
OutputSection to getSymbolValue() without somehow accessing the created
addressState. The suggestion was that by making a pointer that would go out
of scope we would find out by ASAN/MSAN or a crash if someone had misused
currentAddressState.
Differential Revision: https://reviews.llvm.org/D34345
llvm-svn: 307637
This is enough to link a working hello world executable, with
a call to an imported function, a string constant passed to
the imported function, and loads from a global variable.
Differential Revision: https://reviews.llvm.org/D34964
llvm-svn: 307629
This is part of the continuing effort to increase parity between
LLD and MSVC PDBs. link still doesn't like our PDBs, so the most
obvious thing to check was whether adding an empty publics stream
would get it to do something else. It still fails in the same way
but at least this removes one more variable from the equation.
The next logical step would be to try creating an empty globals
stream.
Differential Revision: https://reviews.llvm.org/D35224
llvm-svn: 307598
lld-link is apparently a symlink to lld. Our pdb writing code
uses llvm::sys::fs::getMainExecutable() and writes that value
into the PDB, which will resolve symlinks etc. But what we
really want is the exact value of argv[0], which matches what
the MS linker does. Fix this by just writing argv[0] instead
of calling getMainExecutable.
llvm-svn: 307592
This was originally reverted because of two issues.
1) Printing ANSI color escape codes even when outputting to
a file
2) Module name comparisons were failing when comparing a PDB
generated on one machine to a PDB generated on another
machine.
I attempted to fix#2 by adding command line options which let
you specify prefixes to strip from the beginning of embedded
paths, which effectively lets us specify a path to "base" each
PDB from and only compare the parts under the base. But this is
tricky because PDB paths always use Windows path syntax, even
when they are created on non-Windows hosts. A problem still
existed when constructing the prefix to strip, where we were
accidentally using a host-specific path separator instead of
a Windows path separator.
This resubmission fixes the issue on Linux (and I have verified
that the test now passes on Linux).
llvm-svn: 307571
A test was checked in on Friday that worked by checking in an
object file and PDB generated locally by MSVC, and then having
the test run lld-link on the object file and diffing LLD's PDB
against the checked in PDB.
This failed because part of the diffing algorithm involves
determining if two modules are the same, and if so drilling into
the module and diffing individual fields of the module. The
only thing we can use to make this determination though is the
"name" of the module, which is a path to where the module (obj
file) was read from on the machine where it was linked. This
fails for obvious reasons when comparing a PDB generated on one
machine to a PDB on another machine.
The fix employed here is to add two command line options to the
diff subcommand, which allow the user to specify a "binary root
path". The bin root path, if specified, is stripped from the
beginning of any embedded PDB paths. The test is updated to
specify the user's local test output directory for the left
PDB, and is hardcoded to the location where the original PDB
was created for the right PDB. This way all the equivalence
comparisons should succeed.
llvm-svn: 307555
This reverts commit 147f45ff24456aea59575fa4ac16c8fa554df46a.
Revert "Revert "Revert "Revert "Replace trivial use of external rc.exe by writing our own .res file.""""
This reverts commit 61a90a67ed54a1f0dfeab457b65abffa129569e4.
The patches were intially reverted because they were causing a failure
on CrWinClangLLD. Unfortunately, this was done haphazardly and didn't
compile, so the revert was reverted again quickly to fix this. One that
was done, the revert of the revert was itself reverted. This allowed me
to finally fix the actual bug in r307452. This patch re-enables the
code path that had originally been causing the bug, now that it (should)
be fixed.
llvm-svn: 307460
Summary:
The original cvtres.exe sets the high bit when an identifier offset
points to a string. Even though this is not mentioned in the spec, and
in fact does not seem to cause errors with most cases, for some reason
this causes a failure in Chromium where the new resource file is not
verified as a new version. This patch sets this high bit flag, and also
adds a test case to check that the output of our library is always
identical to original cvtres.
Reviewers: zturner, ruiu
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D35099
llvm-svn: 307452
1) Don't write a /src/headerblock stream. This appears to be
written conditionally by MSVC, but it's not clear what the
condition is. For now, just remove it since we dont' know
what it is anyway and the particular pdb we've checked in
for the test doesn't have one.
2) Write a valid timestamp for the PDB file signature. This
leads to non-reproducible builds, but it matches the default
behavior of link, so it should be out default as well. If
we need reproducibility, we should add a separate command
line option for it that is off by default.
3) Write an empty FPO stream. MSVC seems to always write an
FPO stream. This change makes the stream directory match
up, although we still need to make the contents of the FPO
stream match.
llvm-svn: 307436
Some platforms require an explicit specialization of std::hash
for PdbRaw_FeaturesSig. Also a test involving case sensitivity
needed to be fixed. For now that particular check just accepts
any path even if they're completely different. Long term we
should output paths in the correct case to match MSVC.
llvm-svn: 307426
Without this we would just append whatever the user
wrote on the command line, so if we're in C:\foo
and we run lld-link bar/baz.obj, we would write
C:\foo\bar/baz.obj in various places in the PDB.
MSVC linker does not do this, so we shouldn't either.
This fixes some differences in the diff test, so we
update the test as well.
Differential Revision: https://reviews.llvm.org/D35092
llvm-svn: 307423
A couple of things were different about our generated PDBs.
1) We were outputting the wrong Version on the PDB Stream.
The version we were setting was newer than what MSVC is setting.
It's not clear what the implications are, but we change LLD
to use PdbImplVC70, as MSVC does.
2) For the optional debug stream indices in the DBI Stream, we
were outputting 0 to mean "the stream is not present". MSVC
outputs uint16_t(-1), which is the "correct" way to specify
that a stream is not present. So we fix that as well.
3) We were setting the PDB Stream signature to 0. This is supposed
to be the result of calling time(nullptr). Although this leads
to non-deterministic builds, a better way to solve that is by
having a command line option explicitly for generating a
reproducible build, and have the default behavior of lld-link
match the default behavior of link.
To test this, I'm making use of the new and improved `pdb diff`
sub command. To make it suitable for writing tests against, I had
to modify the diff subcommand slightly to print less verbose output.
Previously it would always print | <column> | <value1> | <value2> |
which is quite verbose, and the values are fragile. All we really
want to know is "did we produce the same value as link?" So I added
command line options to print a single character representing the
result status (different, identical, equivalent), and another to
hide the value display. Note that just inspecting the diff output
used to write the test, you can see some things that are obviously
wrong. That is just reflective of the fact that this is the state
of affairs today, not that we're asserting that this is "correct".
We can use this as a starting point to discover differences, fix
them, and update the test.
Differential Revision: https://reviews.llvm.org/D35086
llvm-svn: 307422
In preparation for the addition of rangeThunks() calculate the addresses
of all the inputSections so that ThunkSections can be inserted at the right
place.
Differential Revision: https://reviews.llvm.org/D34688
llvm-svn: 307373
This is relative to PR33173,
Previously if something wrong happened on DWARF parsers side during parsing
object for building gdb index (like was in PR: unsupported relocation)
then LLD continued and finished the link. DWARF parsers sure showed error
message on their side, but that is all.
Patch changes behavior to fail the link in this case and show more
detailed message.
Differential revision: https://reviews.llvm.org/D34814
llvm-svn: 307370
The assignAddresses() function accumulates state in the LinkerScript that
prevents it from being called multiple times. This change moves the state
into a separate structure AddressState that is created at the start of the
function and disposed of at the end.
CurAddressState is used rather than passing a reference to the state as a
parameter to the functions used by assignAddresses(). This is because the
getSymbolValue function needs to be executed in the context of AddressState
but it is stored in ScriptParser when AddressState is not available.
The AddressState is also used in a limited context by processCommands()
Differential Revision: https://reviews.llvm.org/D34345
llvm-svn: 307367
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: 307364
Based strictly on the name, this seems to have something to do
width edit & continue. The goal of this patch has nothing to do
with supporting edit and continue though. msvc link.exe writes
very basic information into this area even when *not* compiling
with support for E&C, and so the goal here is to bring lld-link
to parity. Since we cannot know what assumptions standard tools
make about the content of PDB files, we need to be as close as
possible.
This ECNames data structure is a standard PDB string hash table.
link.exe puts a single string into this hash table, which is the
full path to the PDB file on disk. It then references this string
from the module descriptor for the compiler generated `* Linker *`
module.
With this patch, lld-link will generate the exact same sequence of
bytes as MSVC link for this subsection for a given object file
input (as reported by `llvm-pdbutil bytes -ec`).
llvm-svn: 307356
Summary:
The capture() function was removed in r306625. This should fix PGO breakages
reported by Michael Zolotukhin.
Reviewers: mzolotukhin
Subscribers: sanjoy, llvm-commits
Differential Revision: https://reviews.llvm.org/D35088
llvm-svn: 307320
Summary:
There are a variety of records that open scopes: function scopes, block
scopes, and inlined call site scopes. These symbol records contain
Parent and End fields with the offsets of other symbol records. The End
field contains the offset of the matching S_END or S_INLINESITE_END
record. The Parent field contains the offset of the parent record, or 0
if this is a top-level scope (i.e. a function).
With this change, `llvm-pdbutil pretty -all` no longer crashes on PDBs
produced by LLD. I haven't tried a real debugger yet.
Reviewers: zturner, ruiu
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34898
llvm-svn: 307278
This reverts commit ae21ee0b6cacbc1efaf4d42502e71da2f0eb45c3.
The initial revert was done in order to prevent ongoing errors on
chromium bots such as CrWinClangLLD. However, this was done haphazardly
and I didn't realize there were test and compilation failures, so this
revert was reverted. Now that those have been fixed, we can revert the
revert of the revert.
llvm-svn: 307227
This reverts commit 5fecbbbe5049665d86834cf69d8f75db4f392308.
The initial revert was done in order to prevent ongoing errors on
chromium bots such as CrWinClangLLD. However, this was done haphazardly
and I didn't realize there were test and compilation failures, so this
revert was reverted. Now that those have been fixed, we can revert the
revert of the revert.
llvm-svn: 307226
This reverts commit 600d52c278e123dd08bee24c1f00932b55add8de.
This patch still seems to break CrWinClangLLD, reverting until I can
find root problem.
llvm-svn: 307189
This patch still seems to break CrWinClangLLD, reverting this once more
until I can discover root problem.
This reverts commit 3dbbc8ce43be50ffde2b1c655c6d3a25796fe78b.
llvm-svn: 307188
This change permits there to be more than one thunk to be associated with
a symbol. For interworking thunks we only require one thunk, but range
extension thunks may require more than one.
Differential Revision: https://reviews.llvm.org/D34037
llvm-svn: 307136
On ARM the interworking thunks are only produced for branch instructions
that can't be changed into a blx instruction so only Thumb callers would
call Thumb thunks and only ARM callers would call ARM thunks. With range
extension thunks branch and link instructions may need a Thunk. These
instructions can be rewritten as a blx and can use either ARM or Thumb
thunks.
We introduce an isCompatibleWith() function so that a caller can check if
an existing Thunk is compatible before reusing it.
Differential Revision: https://reviews.llvm.org/D34035
llvm-svn: 307132
The allocateHeaders() function is called at the end of assignAddresses(), it
decides whether the ELF header and program header table can be allocated to
a PT_LOAD program header. As the function alters state, it prevents
assignAddresses() from being called multiple times.
This change splits out the call to allocateHeaders() from assignAddresses()
this will permit assignAddresses() to be called while processing range
extension thunks without trying to allocateHeaders().
Differential Revision: https://reviews.llvm.org/D34344
llvm-svn: 307131
This is finally getting to the point where output sections are
constructed.
createOrphanCommands and fabricateDefaultCommands are moved out so
they can be merged with existing code in followup commits.
llvm-svn: 307107
Summary:
If the output file is a character file (e.g. /dev/null) unlinking it could
potentially destabilize the user's system. For example,
unlinking causes `lld %input -o /dev/null` to replace /dev/null with a
regular file, which will lead to unexpected behavior in other programs
that read from /dev/null, and worse than expected peformance for
programs that write to /dev/null.
This makes it possible to run the test-release.sh script as root.
Prior to this patch, the ELF/basic.s test would replace
/dev/null with a regular file, which would cause crashes in llvm
test-suite programs that piped /dev/null to stdin.
For example, if you run the test-relase.sh script as root,
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: emaste, llvm-commits
Differential Revision: https://reviews.llvm.org/D34917
llvm-svn: 307092
This is PR28414.
Previously LLD was unable to link following:
(failed with undefined symbol bar)
Version script:
SOME_VERSION { global: *; };
.global _start
.global bar
.symver _start, bar@@SOME_VERSION
_start:
jmp bar
Manual has next description:
.symver name, name2@@nodename
In this case, the symbol name must exist and be defined within the file being assembled. It is similar to name2@nodename.
The difference is name2@@nodename will also be used to resolve references to name2 by the linker
https://sourceware.org/binutils/docs/as/Symver.html
Patch implements that. If we have name@@ver symbol and name is undefined, name@@ver is used to resolve references to name.
If name is defined then multiple definition error is emited, that is consistent with what bfd do.
Differential revision: https://reviews.llvm.org/D33680
llvm-svn: 307077
Script commands are processed before unused synthetic sections are
removed. Therefore, if a linker script matches one of these sections
it'll get emitted as an empty output section because the logic for
removing unused synthetic sections ignores script commands which
could have already matched and captured one of these sections. This
patch fixes that by also removing the unused synthetic sections from
the script commands.
Differential Revision: https://reviews.llvm.org/D34800
llvm-svn: 307037
Since yaml2obj is now able to parse integer values as relocation types,
there is no need to keep hex edited elf object for this test,
we can produce it on fly, just like this patch do.
Differential revision: https://reviews.llvm.org/D34893
llvm-svn: 307032
This patch makes changes to allow sections without the SHF_ALLOC bit to be
assigned to segments in a linker script.
The assignment of output sections to segments is performed in
LinkerScript::createPhdrs. Previously, this function would bail as soon as it
encountered an output section which did not have the SHF_ALLOC bit set, thus
preventing any output section without SHF_ALLOC from being assigned to a
segment.
This restriction has now been removed from LinkerScript::createPhdrs and instead
a check for SHF_ALLOC has been added to LinkerScript::adjustSectionsAfterSorting
to not propagate program headers to sections without SHF_ALLOC which matches the
behaviour of bfd linker scripts.
Differential Revision: https://reviews.llvm.org/D34204
llvm-svn: 307013
A plain empty entry point function that returns 0 seems to produce
a binary that loads and runs fine in wine.
Differential Revision: https://reviews.llvm.org/D34833
llvm-svn: 306963
Summary:
This reverts commit 51931072a7c9a52540baf76fc30ef391d2529a2f.
This revert was originally done because the integrations of the new
WindowsResource library into LLD was causing error in chromium, due to
bugs in how resource sections were handled. These bugs were fixed,
meaning that the features may be reintegrated.
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D34922
llvm-svn: 306941
Type records have a unique type index, but symbol records do
not. Instead, symbol records refer to other symbol records
by referencing their offset in the symbol stream. In a sense
this is the analogue of the TypeIndex, but we are not printing
it in the dumper. Printing it not only gives us more useful
information when manually investigating the contents of a PDB,
but also allows us to write better tests by enabling us to
verify that fields that reference other symbol records do
so correctly.
Differential Revision: https://reviews.llvm.org/D34906
llvm-svn: 306890
This is a short-term fix for PR33650 aimed to get the modules build bots green again.
Remove all the places where we use the LLVM_YAML_IS_(FLOW_)?SEQUENCE_VECTOR
macros to try to locally specialize a global template for a global type. That's
not how C++ works.
Instead, we now centrally define how to format vectors of fundamental types and
of string (std::string and StringRef). We use flow formatting for the former
cases, since that's the obvious right thing to do; in the latter case, it's
less clear what the right choice is, but flow formatting is really bad for some
cases (due to very long strings), so we pick block formatting. (Many of the
cases that were using flow formatting for strings are improved by this change.)
Other than the flow -> block formatting change for some vectors of strings,
this should result in no functionality change.
Differential Revision: https://reviews.llvm.org/D34907
Corresponding LLVM change is r306878.
llvm-svn: 306880
Summary:
There have been bugs with the WindowsResource library, such as incorrect
symbols for addresses. Directly checking the .rsrc in the final PE will
help ensure this doesn't happen again.
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34900
llvm-svn: 306854
This is PR28414.
Previously LLD was unable to link following:
(failed with undefined symbol bar)
```
Version script:
SOME_VERSION { global: *; };
.global _start
.global bar
.symver _start, bar@@SOME_VERSION
_start:
jmp bar
```
Manual has next description:
//
.symver name, name2@@nodename
In this case, the symbol name must exist and be defined within the file being assembled. It is similar to name2@nodename.
**The difference is name2@@nodename will also be used to resolve references to name2 by the linker**
https://sourceware.org/binutils/docs/as/Symver.html
//
Patch implements that. If we have name@@ver symbol and name is undefined,
name@@ver is used to resolve references to name.
Differential revision: https://reviews.llvm.org/D33680
llvm-svn: 306813
This reverts commit d4c7e9fc63c10dbab0c30186ef8575474a704496.
This is done in order to address the failure of CrWinClangLLD etc. bots.
These throw an error of "side-by-side configuration is incorrect" during
compilation, which sounds suspiciously related to these manifest
changes.
Revert "Switch external cvtres.exe for llvm's own resource library."
This reverts commit 71fe8ef283a9dab9a3f21432c98466cbc23990d1.
llvm-svn: 306618
We could have add this function either Symbol or SymbolBody. I added it
to Symbol at first. But I noticed that if I've added it to SymbolBody,
we could've removed SymbolBody::setName(). So I'll do that in this patch.
llvm-svn: 306590
Summary:
In order to do this without switching on the symbol kind multiple times,
I created Defined::getChunkAndOffset and use that instead of
SymbolBody::getRVA in the inner relocation loop.
Now we get the symbol's chunk before switching over relocation types, so
we can test if it has been discarded outside the inner relocation type
switch. This also simplifies application of section relative
relocations. Previously we would switch on symbol kind to compute the
RVA, then the relocation type, and then the symbol kind again to get the
output section so we could subtract that from the symbol RVA. Now we
*always* have an OutputSection, so applying SECREL and SECTION
relocations isn't as much of a special case.
I'm still not quite happy with the cleanliness of this code. I'm not
sure what offsets and bases we should be using during the relocation
processing loop: VA, RVA, or OutputSectionOffset.
Reviewers: ruiu, pcc
Reviewed By: ruiu
Subscribers: majnemer, inglorion, llvm-commits, aprantl
Differential Revision: https://reviews.llvm.org/D34650
llvm-svn: 306566
Add support for the most common SPARC relocations.
Make DT_PLTGOT point to the PLT on SPARC.
Mark the PLT as executable on SPARC.
This adds a basic test that creates a SPARV9 executable
that invokes the exit system call on OpenBSD.
Patch by Mark Kettenis.
Differential Revision: https://reviews.llvm.org/D34618
llvm-svn: 306565
This is PR33596. Previously LLD would crash
because BYTE command synthesized output section,
but it was not assigned to Sec member of OutputSectionCommand.
Behaviour of -script and -r combination is not well defined,
but it seems after this change LLD naturally inherits behavior of
GNU linkers - creates output section requested in script and does not
crash anymore.
Differential revision: https://reviews.llvm.org/D34676
llvm-svn: 306527
This fixes PR33598.
Size field for undefined symbols is not significant.
Setting it to fixed value, like zero, may be useful though.
For example when we have 2 DSO's, like in this PR, if lower level DSO may
change slightly (in part of some symbol's st_size) and higher-level DSO is
rebuilt, then tools that monitoring checksum of high level DSO file can notice
it and trigger cascade of some other unnecessary actions.
If we set st_size to zero, that can be avoided.
Differential revision: https://reviews.llvm.org/D34673
llvm-svn: 306526
When -ffunction-sections and ARM C++ exceptions are used each .text.suffix
section will have at least one .ARM.exidx.suffix section and may have an
additional .ARM.extab.suffix section if the unwinding instructions are too
large to inline into the .ARM.exidx table entry. For a large program without
a linker script this can lead to a large number of section header table
entries that can increase the size of the ELF file.
This change introduces a default rule for .ARM.extab.* to be placed in
a single output section called .ARM.extab . This follows the behavior of
ld.gold and ld.bfd.
fixes pr33407
Differential Revision: https://reviews.llvm.org/D34678
llvm-svn: 306522
It is somewhat pointless to check that a specific error is not
produced. That is already checked by the ld.lld exit value.
Instead make the test a bit stronger by checking that the output file
has the expected symbol and section.
llvm-svn: 306496
Summary: The testing on the resource section of executables produced by lld has been very lax, and allowed a major bug to go unnoticed when we switched from shelling out to cvtres.exe to using llvm's own library. These additional tests should cover all the major failure points.
Reviewers: zturner, ruiu
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34664
llvm-svn: 306465
This patch fills holes in executable sections with 0xd4 (ARM) or
0xef (MIPS). These trap instructions were suggested by Theo de Raadt.
llvm-svn: 306322
This patch removes the dependency on the external rc.exe tool by writing
a simple .res file using our own library. In this patch I also added an
explicit definition for the .res file magic. Furthermore, I added a
unittest for embeded manifests and fixed a bug exposed by the test.
llvm-svn: 306311
Summary:
They do the obvious thing: provide the section index of .bss and the
offset of the symbol in .bss.
Reviewers: ruiu
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34628
llvm-svn: 306304
Over time we've started to add inputs and test cases using the .yaml
extension, which seems to be preferred over the .objtxt extension that
we were using initially. One nice thing about using .yaml is that it
triggers existing editor highlighting and formatting support.
Fix two pdb*.yaml test cases that I added that weren't being run as part
of check-lld.
llvm-svn: 306303
Summary:
The main change is that we can have SECREL and SECTION relocations
against ___safe_se_handler_table, which is important for handling the
debug info in the MSVCRT.
Previously we were using DefinedRelative for __safe_se_handler_table and
__ImageBase, and after we implement CFGuard, we plan to extend it to
handle __guard_fids_table, __guard_longjmp_table, and more. However,
DefinedRelative is really only suitable for implementing __ImageBase,
because it lacks a Chunk, which you need in order to figure out the
output section index and output section offset when resolving SECREl and
SECTION relocations.
This change renames DefinedRelative to DefinedSynthetic and gives it a
Chunk. One wart is that __ImageBase doesn't have a chunk. It points to
the PE header, effectively. We could split DefinedRelative and
DefinedSynthetic if we think that's cleaner and creates fewer special
cases.
I also added safeseh.s, which checks that we don't emit a safe seh table
entries pointing to garbage collected handlers and that we don't emit a
table at all when there are no handlers.
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: inglorion, pcc, llvm-commits, aprantl
Differential Revision: https://reviews.llvm.org/D34577
llvm-svn: 306293
Most "reserved" symbols are in ElfSym and it looks like there's no
reason to not do the same thing for _GLOBAL_OFFSET_TABLE_. This should
help https://reviews.llvm.org/D34618 too.
llvm-svn: 306292
On many architectures gcc and clang will recognize _GLOBAL_OFFSET_TABLE_ - .
and produce a relocation that can be processed without needing to know the
value of _GLOBAL_OFFSET_TABLE_. This is not always the case; for example ARM
gcc produces R_ARM_BASE_PREL but clang produces the more general
R_ARM_REL32 to _GLOBAL_OFFSET_TABLE_. To evaluate this relocation
correctly _GLOBAL_OFFSET_TABLE_ must be defined to be the either the base of
the GOT or end of the GOT dependent on architecture..
If/when llvm-mc is changed to recognize _GLOBAL_OFFSET_TABLE_ - . this
change will not be necessary for new objects. However there may still be
old objects and versions of clang.
Differential Revision: https://reviews.llvm.org/D34355
llvm-svn: 306282
This is useful when an upper limit on the cache size needs to be
controlled independently of the amount of the amount of free space.
One use case is a machine with a large number of cache directories
(e.g. a buildbot slave hosting a large number of independent build
jobs). By imposing an upper size limit on each cache directory,
users can more easily estimate the server's capacity.
Differential Revision: https://reviews.llvm.org/D34547
llvm-svn: 306126
Summary:
For SECTION relocations against absolute symbols, MSVC emits the largest
output section index plus one. I've implemented that by threading a
global variable through DefinedAbsolute that is filled in by the Writer.
A more library-oriented approach would be to thread the Writer through
Chunk::writeTo and SectionChunk::applyRel*, but Rui seems to prefer
doing it this way.
MSVC rejects SECREL relocations against absolute symbols, but only when
the relocation is in a real output section. When the relocation is in a
CodeView debug info section destined for the PDB, it seems that this
relocation error is suppressed, and absolute symbols become zeros in the
object file. This is easily implemented by checking the input section
from which we're applying relocations.
This should fix errors about __safe_se_handler_table and
__guard_fids_table when linking the CRT and generating a PDB.
Reviewers: ruiu
Subscribers: aprantl, llvm-commits
Differential Revision: https://reviews.llvm.org/D34541
llvm-svn: 306071
Now you run llvm-pdbutil dump <options>. This is a followup
after having renamed the tool, whereas before raw was obviously
just the style of dumping, whereas now "dump" is the action to
perform with the "util".
llvm-svn: 306055
Previously, when symbol A is renamed B, both A and B end up having
the same name. This is because name is a symbol's attribute, and
we memcpy symbols for symbol renaming.
This pathc saves the original symbol name and restore it after memcpy
to keep the original name.
This patch shouldn't change program's meaning, but names in symbol
tables make more sense than before.
llvm-svn: 306036
Summary:
The main complexity in adding symbol records is that we need to
"relocate" all the type indices. Type indices do not have anything like
relocations, an opaque data structure describing where to find existing
type indices for fixups. The linker just has to "know" where the type
references are in the symbol records. I added an overload of
`discoverTypeIndices` that works on symbol records, and it seems to be
able to link the standard library.
Reviewers: zturner, ruiu
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D34432
llvm-svn: 305933
This works around a strange interaction with Authenticode signatures,
in which a signed PE executable with {Major,Minor}LinkerVersion = 0.0
fails to validate on Windows 7 (but is OK on Windows 10). Setting the
linker version to 14.0 (which is what VS2015 outputs) makes it work
again.
Patch by Simon Tatham <simon.tatham@arm.com>.
llvm-svn: 305929
The --exclude-libs option is not a popular option, but at least some
programs in Android depend on it, so it's worth to support it.
Differential Revision: https://reviews.llvm.org/D34422
llvm-svn: 305920
VC2017 contains these new symbols as undefined symobls. They are used
for /guard:cf. Since we do not support the control flow guard, but we
want to at least ignore these symbols so that we can link against VS2017
libraries.
Fixes https://bugs.chromium.org/p/chromium/issues/detail?id=727193.
llvm-svn: 305876
We forgot to serialize these because llvm-readobj didn't dump them. They
are typically all zeros in an object file. The linker fills them in with
relocations before adding them to the PDB. Now we can properly round
trip these symbols through pdb2yaml -> yaml2pdb.
I made these fields optional with a zero default so that we can elide
them from our test cases.
llvm-svn: 305857
The option numbers in the macro were off by one which
leads to some confusion. There are actually 12 arguments
to this macro.
Differential Revision: https://reviews.llvm.org/D34413
llvm-svn: 305823
Summary:
Previously we didn't add debug info chunks to the SparseChunks array, so
they didn't participate in section GC. Now we do.
Reviewers: ruiu
Subscribers: aprantl, llvm-commits
Differential Revision: https://reviews.llvm.org/D34356
llvm-svn: 305811
This is patch for GSoC project, bash-completion for clang.
To use this on bash, please run `source clang/utils/bash-autocomplete.sh`.
bash-autocomplete.sh is code for bash-completion.
In this patch, Options.td was mainly changed in order to add value class
in Options.inc.
llvm-svn: 305805
I found this while trying to build u-boot. It uses -Ttext in
combination with linker scripts.
My first reaction was to change the linker scripts to have the correct
value, but I found that it is actually quite convenient to have -Ttext
take precedence.
By having just
.text : { *(.text) }
In the script, they can define the text address in a single Makefile
and pass it to ld with -Ttext and for the C code with
-DFoo=value. Doing the same with linker scripts would require them to
be generated during the build.
llvm-svn: 305766
Petr Hosek