| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
| |
The tests assume the path separator is '/', but if you run
them on Windows it is '\'. As a result the tests are failing
on Windows. This should be the minimal change to make these
tests to pass on Windows platform.
Differential Revision: http://reviews.llvm.org/D4710
llvm-svn: 214990
|
|
|
|
|
|
|
|
| |
In some cases the address of a function will be materialized with a movw/movt
pair. If the function is a thumb function, the low bit needs to be set on
the movw immediate value.
llvm-svn: 214277
|
|
|
|
|
|
|
|
|
|
|
|
| |
The -sectalign option is used to increase the alignment required for a section.
It required some reworking of how the __TEXT segment is laid out because that
segment also contains the mach_header and load commands. And the size of load
commands depend on the number of segments, sections, and dependent dylibs used.
Using this option will simplify some future test cases because the final
address of code can be pinned down, making tests of its content easier.
llvm-svn: 214268
|
|
|
|
| |
llvm-svn: 214145
|
|
|
|
|
|
|
|
|
|
|
| |
All iOS arm processor support switching between arm and thumb mode at call sites
by using the BLX instruction (instead of BL). But the compiler does not know
the implementation mode for extern functions, so the linker must update BL/BLX
instructions to match what is linked is actually linked together. In addition,
pointers to functions (such as vtables) must have the low bit set if the target
of the pointer is a thumb mode function.
llvm-svn: 214140
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes compilers emit data into code sections (e.g. constant pools or
jump tables). These runs of data can throw off disassemblers. The solution
in mach-o is that ranges of data-in-code are encoded into a table pointed to
by the LC_DATA_IN_CODE load command.
The way the data-in-code information is encoded into lld's Atom model is that
that start and end of each data run is marked with a Reference whose offset
is the start/end of the data run. For arm, the switch back to code also marks
whether it is thumb or arm code.
llvm-svn: 213901
|
|
|
|
|
|
|
|
|
| |
This patch just supports marking ranges that are thumb code (vs arm code).
Future patches will mark data and jump table ranges. The ranges are encoded
as References with offsetInAtom being the start of the range and the target
being the same atom.
llvm-svn: 213712
|
|
|
|
|
|
|
| |
Update the parse-arm-relocs.yaml test case to run the linker back to back
to ensure all relocations round trip in and out of mach-o.
llvm-svn: 213700
|
|
|
|
| |
llvm-svn: 213592
|
|
|
|
|
|
|
| |
Over time the symbols and relocations have changed for dwarf unwind info
in the __eh_frame section. Add test cases for older and new style.
llvm-svn: 213585
|
|
|
|
| |
llvm-svn: 213362
|
|
|
|
| |
llvm-svn: 213344
|
|
|
|
| |
llvm-svn: 213340
|
|
|
|
|
|
|
|
|
| |
Add support for adding section relocations in -r mode. Enhance the test
cases which validate the parsing of .o files to also round trip. They now
write out the .o file and then parse that, verifying all relocations survived
the round trip.
llvm-svn: 213333
|
|
|
|
|
|
|
|
|
|
|
| |
All architecture specific handling is now done in the appropriate
ArchHandler subclass.
The StubsPass and GOTPass have been simplified. All architecture specific
variations in stubs are now encoded in a table which is vended by the
current ArchHandler.
llvm-svn: 213187
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These behave slightly idiosyncratically in the best of cases, and have
additional hacks layered on top of that for compatibility with badly behaved
build systems (via ld64).
For -lXYZ:
+ If XYZ is actually XY.o then search all library paths for XY.o
+ Otherwise search all library paths, first for libXYZ.dylib, then libXYZ.a
+ By default the library paths are /usr/lib and /usr/local/lib in that order.
For -syslibroot:
+ -syslibroot options apply to absolute paths in the search order.
+ All -syslibroot prefixes that exist are added to the search path *instead*
of the original.
+ If no -syslibroot prefixed path exists, the original is kept.
+ Hacks^WExceptions:
+ If only 1 -syslibroot is given and doesn't contain /usr/lib or
/usr/local/lib, that path is dropped entirely. (rdar://problem/6438270).
+ If the last -syslibroot is "/", all of them are ignored entirely.
(rdar://problem/5829579).
At least, that's my best interpretation of what ld64 does in buildSearchPaths.
llvm-svn: 212706
|
|
|
|
| |
llvm-svn: 212652
|
|
|
|
|
|
|
|
|
|
| |
This converts the very complicated mach-o arm
relocations into the simple Reference Kinds in lld.
The next patch will use the internal Reference kinds
to fix up arm/thumb code.
llvm-svn: 212306
|
|
|
|
| |
llvm-svn: 212247
|
|
|
|
| |
llvm-svn: 212241
|
|
|
|
| |
llvm-svn: 212239
|
|
|
|
|
|
|
| |
It still needs to be tied into BinaryReader, but this allows reasonably
sensible creation of SharedLibrary atoms on MachO.
llvm-svn: 212093
|
|
|
|
| |
llvm-svn: 212072
|
|
|
|
| |
llvm-svn: 212068
|
|
|
|
|
|
|
|
| |
When trying to map atom types to sections, we were iterating through an array
until we hit a sentinel value. There's no need for such dances when range-based
for loops are available.
llvm-svn: 212035
|
|
|
|
|
|
|
|
|
|
|
|
| |
This isn't really the right place to put them in final object files (that would
be __TEXT,__unwind_info), but the format is different between relocatable and
final objects, which means we really need a pass to handle the translation.
For now, re-emitting in __LD,__compact_unwind is harmless (dyld ignores it and
moves straight on to inspecting __TEXT,__eh_frame), and sidesteps an assertion
failure when processing files containing compact-unwind info.
llvm-svn: 212032
|
|
|
|
|
|
|
|
|
| |
Segments must occupy a multiple of the page size in memory (4096 currently). We
check for this when emitting files, but the placement algorithm broke down for
the second non-__TEXT segment encountered: the offset wasn't aligned up to 4096
before starting its layout.
llvm-svn: 212031
|
|
|
|
|
|
|
|
|
| |
Because of how we were calculating fileOffset and fileSize for segments, most
ended up at a single offset in a finalised MachO file. This meant the data
often didn't even get written in the final object, let alone where it would be
useful.
llvm-svn: 212030
|
|
|
|
|
|
|
| |
For .dylib files, we refrain from actually creating any atoms until they're
requested via the "exports" method.
llvm-svn: 212027
|
|
|
|
| |
llvm-svn: 211951
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is first step in reworking how mach-o relocations are processed.
The existing KindHandler is going to become a delgate/helper object for
processing architecture specific references. The KindHandler knows how
to convert mach-o relocations into References and back, as well, as fixing
up the content the relocation is on.
One of the messy things about mach-o relocations is that they sometime
come in pairs, but the pairs still convert to one lld::Reference. So, the
conversion has to detect pairs (arch specific) and change the stride.
llvm-svn: 211921
|
|
|
|
|
|
|
|
|
|
|
| |
The previous function returned true for "s < s", which could completely mess up
the sorting of symbols within a section.
Unfortunately, I don't think there's a robust way to write a test for this.
Anything I come up with will be making assumptions about the particular
implementation of std::sort.
llvm-svn: 211704
|
|
|
|
|
|
|
|
|
| |
When looking through sections with zero-terminated string-literals (__cstring
or __ustring) we were constantly rechecking the first few bytes of the string
for '\0' rather than advancing along. This obviously failed unless all strings
within the section had the same length as that first one.
llvm-svn: 211682
|
|
|
|
|
|
|
|
| |
We were trying to examine the first symbol in a section that we wanted to
atomize by symbols, even when there wasn't one. Instead, we should make the
initial anonymous symbol cover the entire section in that situation.
llvm-svn: 211681
|
|
|
|
| |
llvm-svn: 211367
|
|
|
|
|
|
| |
value in place
llvm-svn: 210979
|
|
|
|
| |
llvm-svn: 210975
|
|
|
|
|
|
| |
Further to this, llvm::sys::swapByteOrder() will be added, acting in-place
llvm-svn: 210974
|
|
|
|
| |
llvm-svn: 210919
|
|
|
|
| |
llvm-svn: 210820
|
|
|
|
| |
llvm-svn: 210801
|
|
|
|
|
|
| |
This will reduce the noise in a followup patch.
llvm-svn: 210800
|
|
|
|
| |
llvm-svn: 210785
|
|
|
|
| |
llvm-svn: 210781
|
|
|
|
| |
llvm-svn: 210741
|
|
|
|
|
|
|
|
| |
Because the files in Core actually depend on these files.
Differential Revision: http://reviews.llvm.org/D4000
llvm-svn: 210710
|
|
|
|
|
|
| |
This is an update for a llvm api change.
llvm-svn: 210689
|
|
|
|
|
|
|
|
|
| |
The previous commit uncovered a bug in the mach-o writer whereby two __text
sections were created. But the test case did not catch that. So I updated
the test case to run the linker a second time, reading the output of the
first pass.
llvm-svn: 210624
|
|
|
|
| |
llvm-svn: 210612
|
|
|
|
|
|
|
| |
In -r mode the sections use the table used to parse .o files. Otherwise
use final exectuable table. No functionality change.
llvm-svn: 210506
|