We need these import since relocations are generated against them.
Patch by Nicholas Wilson!
Differential Revision: https://reviews.llvm.org/D42305
llvm-svn: 322990
This solves the problem that --emit-relocs needs the stack-pointer
to be exported, in order to write out any relocations that reference
the __stack_pointer symbol by its symbol index.
Patch by Nicholas Wilson!
Differential Revision: https://reviews.llvm.org/D42237
llvm-svn: 322911
When writing relocatable files we were exporting for all globals
(including file-local syms), but not for functions. Oops. To be
consistent with non-relocatable output, all symbols (file-local
and global) should be exported. Any symbol targetted by further
relocations needs to be exported. The lack of local function
exports was just an omission, I think.
Second bug: Local symbol names can collide, causing an illegal
Wasm file to be generated! Oops again. This only previously affected
producing relocatable output from two files, where each had a global
with the same name. We need to "budge" the symbol names for locals
that are exported on relocatable output.
Third bug: LLD's relocatable output wasn't writing out any symbol
flags! Thus the local globals weren't being marked as local, and
the hidden flag was also stripped...
Added tests to exercise colliding local names with/without
relocatable flag
Patch by Nicholas Wilson!
Differential Revision: https://reviews.llvm.org/D42105
llvm-svn: 322908
There's some abstraction overhead in the underlying
mechanisms that were being used, and it was leading to an
abundance of small but not-free copies being made. This
showed up on a profile. Eliminating this and going back to
a low-level byte-based implementation speeds up lld with
/DEBUG between 10 and 15%.
Differential Revision: https://reviews.llvm.org/D42148
llvm-svn: 322871
We need to decompose relocation type for N32 / N64 ABI. Let's do it
before any other manipulations with relocation type in the `relocateOne`
routine.
llvm-svn: 322860
The problem we had with it is that anything inside an AT is an
expression, so we failed to parse the section name because of the - in
it.
llvm-svn: 322801
Simplify generation of "names" section by simply iterating
over the DefinedFunctions array.
This even fixes some bugs, judging by the test changes required.
Some tests are asserting that functions are named multiple times,
other tests are asserting that the "names" section contains the
function's alias rather than its original name
Patch by Nicholas Wilson!
Differential Revision: https://reviews.llvm.org/D42076
llvm-svn: 322751
The classes used to print and update time information are in
common, so other linkers could use this as well if desired.
Differential Revision: https://reviews.llvm.org/D41915
llvm-svn: 322736
Previously we always handled -defsym after other commands in command line.
That made impossible to overload values set by -defsym from linker script:
test.script:
foo = 0x22;
-defsym=foo=0x11 -script t.script
would always set foo to 0x11.
That is inconstent with common logic which allows to override command line
options. it is inconsistent with bfd behavior and seems breaks assumption that
-defsym is the same as linker script assignment, as -defsyms always handled out of
command line order.
Patch fixes the handling order.
Differential revision: https://reviews.llvm.org/D42054
llvm-svn: 322625
This is an immutable exported global representing
the start of the heap area. It is a page aligned.
Differential Revision: https://reviews.llvm.org/D42030
llvm-svn: 322609
This is used by __cxa_ataxit to determine the currently
executing DLL. Once we fully support DLLs this will need
to be set to some address within the DLL.
The ELF linker added support for this symbol here:
https://reviews.llvm.org/D33856
Differential Revision: https://reviews.llvm.org/D42024
llvm-svn: 322606
Patch by Colden Cullen.
Currently, when a large PE (>4 GiB) is to be produced, a crash occurs
because:
1. Calling setOffset with a number greater than UINT32_MAX causes the
PointerToRawData to overflow
2. When adding the symbol table to the end of the file, the last section's
offset was used to calculate file size. Because this had overflowed,
this number was too low, and the file created would not be large enough.
This lead to the actual crash I saw, which was a buffer overrun.
This change:
1. Adds comment to setOffset, clarifying that overflow can occur, but it's
somewhat safe because the error will be handled elsewhere
2. Adds file size check after all output data has been created This matches
the MS link.exe error, which looks prints as: "LINK : fatal error
LNK1248: image size (10000EFC9) exceeds maximum allowable size
(FFFFFFFF)"
3. Changes calculate of the symbol table offset to just use the existing
FileSize. This should match the previous calculations, but doesn't rely
on the use of a u32 that can overflow.
4. Removes trivial usage of a magic number that bugged me while I was
debugging the issue
I'm not sure how to add a test for this outside of adding 4GB of object
files to the repo. If there's an easier way, let me know and I'll be
happy to add a test.
Differential Revision: https://reviews.llvm.org/D42010
llvm-svn: 322605
Symbol had both Visibility and getVisibility() and they had different
meanings. That is just too easy to get wrong.
getVisibility() would compute the visibility of a particular symbol
(foo in bar.o), and Visibility stores the computed value we will put
in the output.
There is only one case when we want what getVisibility() provides, so
inline it.
llvm-svn: 322590
We track both the combined visibility that will be used for the output
symbol and the original input visibility of the selected symbol.
Almost everything should use the computed visibility.
I will make the names less confusing an a followup patch.
llvm-svn: 322576
parseInt assumed that it could take a negative number literal (e.g.
"-123"). However, such number is in reality already handled as a
unary operator '-' followed by a number literal, so the number
literal is always non-negative. Thus, this code is dead.
llvm-svn: 322453
When a section placement (AT) command references the section itself,
the physical address of the section in the ELF header was calculated
incorrectly due to alignment happening right after the location
pointer's value was captured.
The problem was diagnosed and the first version of the patch written
by Erick Reyes.
llvm-svn: 322421
See https://bugs.llvm.org/show_bug.cgi?id=35533, and D40844
Things covered:
* Removing duplicate data segments (as determined by COMDATs emitted
by the frontend)
* Removing duplicate globals and functions in COMDATs
* Checking that each time a COMDAT is seen it has the same symbols
as at other times (ie it's a stronger check than simply giving all
the symbols in the COMDAT weak linkage)
Patch by Nicholas Wilson!
Differential Revision: https://reviews.llvm.org/D40845
llvm-svn: 322415
This is useful for emscripten or other tools that want to
selectively exports symbols without necessarily changing the
source code.
Differential Revision: https://reviews.llvm.org/D42003
llvm-svn: 322408
Even though a function can have multiple names in the
linking standards (i.e. due to aliases), there can only
be one name for a given function in the NAME section.
Differential Revision: https://reviews.llvm.org/D41975
llvm-svn: 322383
The compiler could not find the conversion from
unique_ptr<WritableMemoryBuffer> to unique_ptr<MemoryBuffer>. This will
hopefully help it along.
llvm-svn: 322365
Previously we checked (HeaderSize == 0) to find out if
PltSection section is IPLT or PLT. Some targets does not set
HeaderSize though. For example PPC64 has no lazy binding implemented
and does not set PltHeaderSize constant.
Because of that using of both IPLT and PLT relocations worked
incorrectly there (testcase is provided).
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D41613
llvm-svn: 322362
AT> lma_region expression allows to specify the memory region
for section load address.
Should fix PR35684.
Differential revision: https://reviews.llvm.org/D41397
llvm-svn: 322359
This allows libraries to supply a list of symbols which are
allowed to be undefined at link time (i.e. result in imports).
This method replaces the existing mechanism (-allow-undefined-file)
used by the clang driver to allow undefined symbols in libc.
For more on motivation for this see:
https://github.com/WebAssembly/tool-conventions/issues/35
In the long run we hope to remove this features and instead
include this information in the object format itself.
Differential Revision: https://reviews.llvm.org/D41922
llvm-svn: 322320
Sam Clegg