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
