The arm64 assembler almost always uses r_extern=1 relocations in which the
r_symbolnum field is the index of the symbol the relocation references. But
sometimes it will set r_extern=0 in which case the linker needs to read the
content of the reloction to determine the target.
Add test case that the r_extern=0 relocation round trips.
llvm-svn: 222200
The arm64 assembler almost always uses r_extern=1 relocations in which the
r_symbolnum field is the index of the symbol the relocation references. But
sometimes it will set r_extern=0 in which case the linker needs to read the
content of the reloction to determine the target.
Add test case that the r_extern=0 relocation round trips.
llvm-svn: 222198
If you have something like
__declspec(align(8192)) int foo = 1;
in your code, the compiler makes the data to be aligned to 8192-byte
boundary, and the linker align the section containing the data to 8192.
LLD always aligned the section to 4192. So, as long as alignment
requirement is smaller than 4192, it was correct, but for larger
requirements, it's wrong.
This patch fixes the issue.
llvm-svn: 222043
AddressOfEntryPoint is overridden after we layout all atoms (until then,
we don't know the entry point address for obvious reason.)
I believe this code is leftover from very early version of the
PE/COFF port that we only had an entry function in a test object file.
llvm-svn: 222026
With --no-align-segments, there is a bug that the fileoffset may not be
congruent to virtual address modulo page alignment.
This patch fixes the problem.
llvm-svn: 221890
MIPS ELF symbols might contain some additional MIPS-specific flags
in the st_other field besides visibility ones. These flags indicate
code properties like microMIPS / MIPS16 encoding, position independent
code etc. We need to transfer the flags from input objects to the
output linked file to write them into the symbol table, adjust symbols
addresses etc.
I add new attribute CodeModel to the DefinedAtom class to hold target
specific flag and to get over YAML/Native format conversion barrier.
Other architectures/targets can extend CodeModel enumeration by their
own flags.
MIPS specific part of this patch adds support for STO_MIPS_MICROMIPS
flag. This flag marks microMIPS symbols. Such symbol should:
a) Has STO_MIPS_MICROMIPS in the corresponding .symtab record.
b) Has adjusted (odd) address in the corresponding .symtab
and .dynsym records.
llvm-svn: 221864
The segment alignment for PT_LOAD segments is set to page size by default, but
if any of the sections require an alignment more than the page size, the segment
alignment property is set to the maximum alignment of the sections that are part
of the segment.
llvm-svn: 221862
The user can use the max-page-size option and set the maximum page size. Dont
check for maximum allowed values for page size, as its what the kernel is
configured with.
Fix the test as well.
llvm-svn: 221858
Each entry in the delay-import address table had a wrong alignment
requirement if 32 bit. As a result it got wrong delay-import table.
Because llvm-readobj doesn't print out that field, we don't have a
test for that. I'll submit a test that would catch this bug after
improving llvm-readobj.
llvm-svn: 221853
The GOT slots were being laid out in a random order by the GOTPass which
caused randomness in the output file.
Note: With this change lld now bootstraps on darwin. That is:
1) link lld using system linker to make lld.1
2) link lld using lld.1 to make lld.2
3) link lld using lld.2 to make lld.3
Now lld.2 and lld.3 are identical.
llvm-svn: 221831
On darwin in final linked images, the __TEXT segment covers that start of the
file. That means in memory a process can see the mach_header (and load commands)
for every loaded image in a process. There are APIs that take and return the
mach_header addresses as a way to specify a particular loaded image.
For completeness, any code can get the address of the mach_header of the image
it is in by using &__dso_handle. In addition there are mach-o type specific
symbols like __mh_execute_header.
The linker needs to supply a definition for any of these symbols if used. But
the address the symbol it resolves to is not in any section. Instead it is the
address of the start of the __TEXT segment.
I needed to make a small change to SimpleFileNode to not override
resetNextIndex() because the Driver creates a SimpleFileNode to hold the
internal/implicit files that the context/writer can create. For some reason
SimpleFileNode overrode resetNextIndex() to do nothing instead of reseting
the index (which mach-o needs if the internal file is an archive).
llvm-svn: 221822
The way lazy binding works in mach-o is that the linker generates a helper
function and has the stub (PLT) initially jump to it. The helper function
pushes an extra parameter then jumps into dyld. The extra parameter is an
offset into the lazy binding info where dyld will find the information about
which symbol to bind and way lazy binding pointer to update.
llvm-svn: 221654
The dynamic table was creating the entry DT_FINI_ARRAY{SZ} even when there was
no .fini_array section. The entries should be creating in the dynamic section
only if there are sections .init_array/.fini_array in the output.
Fixes the tests that checked for errroneous outputs.
llvm-svn: 221588
The value of _DYNAMIC should be pointing at the start of the .dynamic segment.
This was pointing to the end of the dynamic segment. Similarly the value of
_GLOBAL_OFFSET_TABLE_ was not proper too.
llvm-svn: 221587
The parsing routines in the linker script to parse strings encoded in various
formats(hexadecimal, octal, decimal, etc), is needed by the GNU driver too. This
library provides helper functions for all flavors and flavors to add helper
functions which other flavors may make use of.
llvm-svn: 221583
lld generates an ELF by adhering to the ELF spec by aligning vma/fileoffset to a
page boundary, but this becomes an issue when dealing with large pages. This
adds support so that lld generated executables adheres to the ELF spec with the
rule vma % p_align = offset % p_align.
This is supported by the flag --no-align-segments.
This could be the default in few targets like X86_64 to save space on disk.
llvm-svn: 221571
My previous fix to have FileArchive own the member MemoryBuffers was not a
complete solution for darwin because nothing owned the FileArchive object.
Fixed MachOFileNode to be like ELFFileNode and have the graph node own the
archive object.
llvm-svn: 221552
The darwin linker lets you rearrange functions and data for better locality
(less paging). You do this with the -order_file option which supplies a text
file containing one symbol per line.
Implementing this required a small change to LayoutPass to add a custom sorter
hook.
llvm-svn: 221545
When FileArchive loads a member, it instantiates a temporary MemoryBuffer
which points to the member range of the archive file. The problem is that the
object file parsers call getBufferIndentifer() on that temporary MemoryBuffer
and store that StringRef as the _path data member for that lld::File. When
FileArchive::instantiateMember() goes out of scope the MemoryBuffer is deleted
and the File::._path becomes a dangling reference.
The fix adds a vector<> to FileArchive to own the instantiated MemoryBuffers.
In addition it fixes member's path to be the standard format
(e.g. "/path/libfoo.a(foo.o)") instead of just the leaf name.
llvm-svn: 221544
Request `getPairRelocation()` function to get paired relocation type.
That allows us to look up another pairs like R_MICROMIPS_HI16/LO16
in the future.
llvm-svn: 221539
ELFLinkingContext had these two functions, which is really not needed since
the Writer uses a llvm::object template composed of Endianness, Alignment,
Is32bit/64bit. We could just use that and not duplicate functionality.
No Change In Functionality.
llvm-svn: 221523
Mach-O normalized file reader assumes that the entire file is aligned
to a large boundary. If the in-memory file is not aligned properly, it will
abort with an assertion failure in read32/read64. This patch forces the
in-memory file for the unit test to be aligned at 64-byte boundary.
I found these tests are failing on Windows, but theoretically they could
fail on other platform.
llvm-svn: 221508
David Majnemer