| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Reviewed By: ruiu, MaskRay
Differential Revision: https://reviews.llvm.org/D72196
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The following patch avoids segfaulting if the section list is empty when writing a mach-o MH_OBJECT. I ran into this case from a more complicated example trying to dead_strip while using '-r' in lld.
I'm not sure if having empty sections is a legal mach-o, but it does seem that other llvm-binutils tools can ingest such a boring object with out issue. Would it be better to emit an error, emit a warning, or do nothing? It seems that adding a warning diagnostic might be helpful to users, as I did not expect to have a section-less object when the linker was done.
Reviewers: kledzik, ruiu
Subscribers: llvm-commits, jrm
Tags: #lld, #llvm
Differential Revision: https://reviews.llvm.org/D67735
llvm-svn: 372995
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LC_FUNCTION_STARTS
Patch by Nicholas Allegra.
The Mach-O writer calculates the size of load commands multiple times.
First, Util::assignAddressesToSections() (in MachONormalizedFileFromAtoms.cpp)
calculates the size using headerAndLoadCommandsSize() (in
MachONormalizedFileBinaryWriter.cpp), which creates a temporary
MachOFileLayout for the NormalizedFile, only to retrieve its
headerAndLoadCommandsSize. Later, writeBinary() (in
MachONormalizedFileBinaryWriter.cpp) creates a new layout and uses the offsets
from that layout to actually write out everything in the NormalizedFile.
But the NormalizedFile changes between the first computation and the second.
When Util::assignAddressesToSections is called, file.functionStarts is always
empty because Util::addFunctionStarts has not yet been called. Yet
MachOFileLayout decides whether to include a LC_FUNCTION_STARTS command based
on whether file.functionStarts is nonempty. Therefore, the initial computation
always omits it.
Because padding for the __TEXT segment (to make its size a multiple of the
page size) is added between the load commands and the first section, LLD still
generates a valid binary as long as the amount of padding happens to be large
enough to fit LC_FUNCTION_STARTS command, which it usually is.
However, it's easy to reproduce the issue by adding a section of a precise
size. Given foo.c:
__attribute__((section("__TEXT,__foo")))
char foo[0xd78] = {0};
Run:
clang -dynamiclib -o foo.dylib foo.c -fuse-ld=lld -install_name
/usr/lib/foo.dylib
otool -lvv foo.dylib
This should produce:
truncated or malformed object (offset field of section 1 in LC_SEGMENT_64
command 0 not past the headers of the file)
This commit:
- Changes MachOFileLayout to always assume LC_FUNCTION_STARTS is present for
the initial computation, as long as generating LC_FUNCTION_STARTS is
enabled. It would be slightly better to check whether there are actually
any functions, since no LC_FUNCTION_STARTS will be generated if not, but it
doesn't cause a problem if the initial computation is too high.
- Adds a test.
- Adds an assert in MachOFileLayout::writeSectionContent() that we are not
writing section content into the load commands region (which would happen
if the offset was calculated too low due to the initial load commands size
calculation being too low). Adds an assert in
MachOFileLayout::writeLoadCommands to validate a similar situation where
two size-of-load-commands computations are expected to be equivalent.
llvm-svn: 358545
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
|
|
|
|
| |
llvm-svn: 317657
|
|
|
|
| |
llvm-svn: 317650
|
|
|
|
|
|
|
|
|
|
| |
New lld's files are spread under lib subdirectory, and it isn't easy
to find which files are actually maintained. This patch moves maintained
files to Common subdirectory.
Differential Revision: https://reviews.llvm.org/D37645
llvm-svn: 314719
|
|
|
|
|
|
|
|
|
|
|
|
| |
This creates a new library called BinaryFormat that has all of
the headers from llvm/Support containing structure and layout
definitions for various types of binary formats like dwarf, coff,
elf, etc as well as the code for identifying a file from its
magic.
Differential Revision: https://reviews.llvm.org/D33843
llvm-svn: 304864
|
|
|
|
|
|
|
|
| |
This would trigger an assertion at runtime otherwise.
Differential Revision: https://reviews.llvm.org/D26482
llvm-svn: 286562
|
|
|
|
|
|
|
| |
Adopt r280128 in lld, specializing ilist_alloc_traits rather than
reinventing the wheel.
llvm-svn: 280566
|
|
|
|
| |
llvm-svn: 279458
|
|
|
|
|
|
|
| |
Use ilist_half_embedded_sentinel_traits for the list of
lld::mach_o::normalized::TrieEdge, rather than duplicating the code.
llvm-svn: 278523
|
|
|
|
|
|
|
|
|
| |
We should be using one of BIND_OPCODE_SET_DYLIB_SPECIAL_IMM, BIND_OPCODE_SET_DYLIB_ORDINAL_IMM,
and BIND_OPCODE_SET_DYLIB_ORDINAL_ULEB depending on whether ordinals are <= 0, <= 15, > 15.
This matches the behaviour of ld64.
llvm-svn: 278407
|
|
|
|
|
|
|
|
|
|
|
|
| |
as last time.
We already had logic for binding opcodes had the same addend as last time. This adds
the cases where the ordinal, symbol name, type, and segment offsets are the same as
the last emitted ordinal.
This gets us one step closer to emitting rebase opcodes as compressed as ld64 can manage.
llvm-svn: 278405
|
|
|
|
|
|
|
|
|
|
| |
Using vmsize to populate this file works when outputing MachO images, but fails
when outputting relocatable objects. This patch fixes the computation to use
file offsets, which works for both output types.
Fixes <rdar://problem/27727666>
llvm-svn: 278297
|
|
|
|
|
|
|
| |
This matches the behaviour of ld64 which initializes the string table with
' ' then '\0'. lld only had the '\0' and needed the ' '.
llvm-svn: 278071
|
|
|
|
|
|
|
|
| |
The export trie was being emitted in the order the nodes were
added to the vector, but instead needs to be visited in the order
that the nodes are traversed. This matches the behaviour of ld64.
llvm-svn: 277869
|
|
|
|
|
|
| |
copies.
llvm-svn: 276935
|
|
|
|
| |
llvm-svn: 276928
|
|
|
|
|
|
|
|
|
| |
This patch causes LLD to build stabs debugging symbols for files containing
DWARF debug info, and to propagate existing stabs symbols for object files
built using '-r' mode. This enables debugging of binaries generated by LLD
from MachO objects.
llvm-svn: 276921
|
|
|
|
|
|
| |
Thanks to Rui for pointing out this warning was firing.
llvm-svn: 264978
|
|
|
|
|
|
| |
Thanks to Rui for pointing out this warning was firing.
llvm-svn: 264977
|
|
|
|
|
|
|
|
| |
These methods were responsible for some of the few remaining calls
to llvm::errorCodeToError. Converting them makes us have more Error's
in the api and fewer error_code's.
llvm-svn: 264974
|
|
|
|
|
|
|
| |
This converts the writeFile method, as well as some of the ones it calls
in the normalized binary file writer and yaml writer.
llvm-svn: 264961
|
|
|
|
|
|
|
| |
On a 32-bit output, we may write LC_MAIN (which contains a uint64_t) to
an unaligned address. This changes it to use a memcpy instead which is UB safe.
llvm-svn: 264232
|
|
|
|
|
|
|
| |
On a 32-bit output, we may write LC_SOURCE_VERSION (which contains a uint64_t) to
an unaligned address. This changes it to use a memcpy instead which is UB safe.
llvm-svn: 264202
|
|
|
|
| |
llvm-svn: 264114
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also added the defaults for whether to generate this load command, which
the cmdline options are able to override.
There was also a difference to ld64 which is fixed here in that ld64 will
generate an empty data in code command if requested.
rdar://problem/24472630
llvm-svn: 260191
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This load command generates data in the LINKEDIT section which
is a list of ULEB128 delta's to all of the functions in the __text section.
It is then 0 terminated and pointer aligned to pad.
ld64 exposes the -function-starts and no-function-starts cmdline options
to override behaviour from the defaults based on file types.
rdar://problem/24472630
llvm-svn: 260188
|
|
|
|
|
|
|
|
|
|
|
| |
The initial segment protection was also being used to set the maximum
segment protection level. Instead, the maximum should be set according
to the architecture we are linking. For example on Mac OS it should be
RWX on most pages, but on iOS is often on R_X.
rdar://problem/24515136
llvm-svn: 259966
|
|
|
|
|
|
|
|
|
|
|
|
| |
We currently tag on a "__LINKEDIT" when we are emitting the segments.
However, an upcoming patch aims to set the initprot and maxprot segment members
to their correct values, and in order to share code, its better to create this
segment for real and handle it in buildFileOffsets the same way ld64 does.
The commit for segment protections will add a test for this all being correct so
no test here until that code is committed.
llvm-svn: 259960
|
|
|
|
|
|
|
|
|
|
|
| |
On Mac OS 10.5 and later, with X86_64 and outputting a dynamic executable,
ld64 set the CPU_SUBTYPE_LIB64 mask on the cpusubtype in the mach_header.
This adds the same functionality to lld.
rdar://problem/24507177
llvm-svn: 259826
|
|
|
|
|
|
|
|
|
| |
This is of the form A.B.C.D.E and to match ld64's behaviour, is
always output to files, even when the version is 0.
rdar://problem/24472630
llvm-svn: 259746
|
|
|
|
|
|
|
|
|
|
|
| |
In the case where we are emitting to an object file, the platform is
possibly unknown, and the source object files contained load commands
for version min, we can take the maximum of those min versions and
emit in in the output object file.
This test also tests r259739.
llvm-svn: 259742
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the command line contains something like -macosx_version_min and we
don't explicitly disable generation with -no_version_load_command then
we generate the LC_VERSION_MIN command in the output file.
There's a couple of FIXME's in here. These will be handled soon with
more tests but I didn't want to grow this patch any more than it already was.
rdar://problem/24472630
llvm-svn: 259718
|
|
|
|
|
|
|
|
|
|
|
|
| |
The TrieNode/TrieEdge data structures here are allocated in a bumpptrallocator.
Unfortunately, TrieNode contained a std::list<TrieEdge> and as the allocator doesn't
call the TrieNode destructor, we ended up leaking the memory allocated by the std::list
itself.
Instead we can use an intrusive list as then we save the extra allocations anyway.
llvm-svn: 258725
|
|
|
|
| |
llvm-svn: 257801
|
|
|
|
|
|
|
|
|
| |
appropriate bits.
This fixes the remaining clang regression test failures when linking clang with
lld on Darwin.
llvm-svn: 255390
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
table.
The first entry in the MachO symbol table is always the empty string: make sure
we reserve space for it, or we will overflow the symbol table by one byte.
No test case - this manifests as an occasional memory error. In the near future
I hope to set up a bot building and runnnig LLD with sanitizers - that should
catch future instances of this issue.
llvm-svn: 255178
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D14553
llvm-svn: 252661
|
|
|
|
| |
llvm-svn: 251637
|
|
|
|
|
|
|
|
|
| |
This is a basic initial implementation of the -flat_namespace and
-undefined options for LLD-darwin. It ignores several subtlties,
but the result is close enough that we can now link LLVM (but not
clang) on Darwin and pass all regression tests.
llvm-svn: 248732
|
|
|
|
| |
llvm-svn: 244849
|
|
|
|
|
|
| |
way of the default ops (copy construction, assignment, etc)
llvm-svn: 244836
|
|
|
|
| |
llvm-svn: 237841
|
|
|
|
|
|
|
|
| |
This patch defines implicit conversion between integers and PowerOf2
instances, so uses of the classes is now implicit and look like
regular integers. Now we are ready to remove the scaffolding.
llvm-svn: 233245
|
|
|
|
|
|
|
|
|
|
| |
This patch is to make instantiation and conversion to an integer explicit,
so that we can mechanically replace all occurrences of the class with
integer in the next step.
Now get() returns an alignment value rather than its log2 value.
llvm-svn: 233242
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fix the binary file reader to properly read dyld version info.
Update the install_name test case to properly test the binary reader. We can't use '-print_atoms' as the output format is 'native' yaml and it does not contains the dyld current and compatibility versions.
Also change the timestamp value of LD_ID_DYLD to match the one generated by ld64.
The dynamic linker (dyld) used to expects different values for timestamp in LD_ID_DYLD and LD_LOAD_DYLD for prebound images. While prebinding is deprecated, we should probably keep it safe and match ld64.
Reviewers: kledzik
Subscribers: llvm-commits
Projects: #lld
Differential Revision: http://reviews.llvm.org/D6736
llvm-svn: 224681
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Work on adding -rpath support to the mach-o linker.
This patch is based on the ld64 behavior for the command line option validation.
It includes a basic test to check that the LC_RPATH load commands are properly generated when that option is used.
It also add LC_RPATH support to the binary reader, but I don't know how to test it though.
Reviewers: kledzik
Subscribers: llvm-commits
Projects: #lld
Differential Revision: http://reviews.llvm.org/D6724
llvm-svn: 224544
|
|
|
|
|
|
|
|
| |
In PR21682 Jean-Daliel Dupas found a leak in the trie builder and suggested
a fix was to use a list instead of SmallVector so that the list elements
could be allocated in the BumpPtrAllocator.
llvm-svn: 223104
|