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
Rui Ueyama