| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 262434
|
|
|
|
| |
llvm-svn: 262431
|
|
|
|
|
|
|
| |
makeErrorFile and parseMemberFiles are now used only in DarwinLdDriver.cpp.
This patch moves them to that file.
llvm-svn: 262423
|
|
|
|
| |
llvm-svn: 262422
|
|
|
|
|
|
|
|
|
|
|
| |
CoreDriver implements a driver for a hypothetical platform.
It is intended to be used in unittests. However, it is actually
redundant because the features are tested using the real driver
for the real platforms. So we can remove this.
http://reviews.llvm.org/D17698
llvm-svn: 262421
|
|
|
|
| |
llvm-svn: 262345
|
|
|
|
| |
llvm-svn: 262195
|
|
|
|
|
|
| |
The preload feature was buggy that we had disabled it even for ELF.
llvm-svn: 262194
|
|
|
|
| |
llvm-svn: 262193
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
UniversalDriver was used as a dispatcher to each platform-specific driver.
It had its own Options.td file. It was not just too much to parse only a
few options (we only want to parse -core, -flavor or argv[0]),
but also interpreted arguments too early. For example, if you invoke lld as
"lld -flavor gnu ... -help", then you'd get the UniversalDriver's help
message instead of GnuDriver's. This patch eliminates the use of Options
from the dispatcher.
http://reviews.llvm.org/D17686
llvm-svn: 262190
|
|
|
|
| |
llvm-svn: 262184
|
|
|
|
| |
llvm-svn: 262181
|
|
|
|
| |
llvm-svn: 262172
|
|
|
|
| |
llvm-svn: 262167
|
|
|
|
| |
llvm-svn: 262166
|
|
|
|
| |
llvm-svn: 262164
|
|
|
|
|
|
| |
It was ELF specific.
llvm-svn: 262163
|
|
|
|
| |
llvm-svn: 262159
|
|
|
|
|
|
| |
I think it is clear by now that the new linker is viable.
llvm-svn: 262158
|
|
|
|
|
|
|
|
|
| |
We have a vector of all of the compact unwind entries anyway, and
its live as long as we need it to be. So instead of copying from that
vector to another, just take references to the range of the original vector
we need for each compact unwind page.
llvm-svn: 260437
|
|
|
|
|
|
| |
covered switch
llvm-svn: 260417
|
|
|
|
|
|
|
|
|
|
| |
The non lazy atoms generated in the stubs pass use an image cache to
hold all of the pointers. On arm archs, this is the __got section,
but on x86 archs it should be __nl_symbol_ptr.
rdar://problem/24572729
llvm-svn: 260271
|
|
|
|
|
|
|
|
|
|
|
|
| |
ld64 aligns most of the stub's to 2 byte alignment, expect for
the stub helper common atoms which are 4 byte aligned.
This adds a new field to StubInfo which tracks this alignment
and ensures that this is the alignment we get in the final image.
rdar://problem/24570220
llvm-svn: 260248
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
This was a bug in our handling of these symbols compared to ld64.
Turns out that ld64 always marks these symbols as being not dead stripped.
llvm-svn: 260185
|
|
|
|
|
|
|
|
|
|
| |
The atom content type enum is used as a tie breaker to sort atoms.
In that case, we want MachHeader to be before typeCode as it really will
be before the code in the final executable.
Test case to follow in the next commit or two.
llvm-svn: 260184
|
|
|
|
|
|
|
| |
These includes were before the #ifndef/#define guards. Moving them to
where they should be.
llvm-svn: 260153
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 259748
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
ld64 sets both S_ATTR_PURE_INSTRUCTIONS and S_ATTR_SOME_INSTRUCTIONS
on __TEXT, __text. We only had the S_ATTR_PURE_INSTRUCTIONS attribute.
rdar://problem/24495801
llvm-svn: 259744
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
Defaulting to unknown matches ld64, but it also makes sure that all
of our code can handle not knowing the platform. For example, a later
commit will add support for version min load commands with an unknown
platform, which is a feature supported by ld64.
No test case here. The next commit will have one with the version min
code that needed this patch.
llvm-svn: 259739
|
|
|
|
|
|
|
|
|
|
|
|
| |
This option is emitted in the min_version load commands.
Note, there's currently a difference in behaviour compared to ld64 in
that we emit a warning if we generate a min_version load command and
didn't give an sdk_version. We need to decide what the correct behaviour
is here as its possible we want to emit an error and force clients to
provide the option.
llvm-svn: 259729
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
http://reviews.llvm.org/D16668
llvm-svn: 259597
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In r259574 I fixed some of the issues with the mach header symbols
and DSO handles.
This is the next issue whereby the __mh_execute_header has to not
be dead stripped, and (to match ld64) should be dynamically referenced.
The test here should also have been added in r259574 to make sure that
we emit this symbol. But checking that it is not only emitted but also
has the correct reference type is fine.
llvm-svn: 259589
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The magic file which contained these symbols inherited from archive
which meant that the resolver didn't add the required atoms as archive
members only get added when referenced. Instead we now inherit from
SimpleFile which always links in the atoms needed.
The second issue was in the handling of these symbols when we emit
the MachO. The mach header symbol needs to be in the atom list as
it gets an offset (0), and being in the atom list makes sure it is
emitted to the symbol table. DSO handles are not emitted to the
symbol table.
rdar://problem/24450654
llvm-svn: 259574
|
|
|
|
|
|
|
|
|
|
|
| |
When we do debug printing of atoms, they expect their parent file
to have an ordinal. Right now we trigger a bunch of asserts.
This doesn't actually manifest in differences in any real tests, but
even if the only thing it does is improve debuggability then its still
useful.
llvm-svn: 259450
|
|
|
|
| |
llvm-svn: 259442
|
|
|
|
|
|
|
|
| |
The ObjCPass is going to need to create pointer sized relocations in
the ObjC sections. This method will be used to give us a target independent
way of getting the correct kind for the refererence.
llvm-svn: 259441
|
|
|
|
|
|
|
|
|
|
| |
An upcoming patch will use this to create lists of ObjC methods.
Adding it now to reduce the amount of code in that patch.
Test cases will follow in the other patch too.
llvm-svn: 259440
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the no_objc_category_merging cmdline option which will
be used in an upcoming commit to disable the category optimizer.
It is on by default in ld64 so we match that here.
Test case will come soon with the patch to make use of this option.
llvm-svn: 259439
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most of the other methods to access Reference's were on DefinedAtom so
this just keeps them all together.
This will be used in a future patch in ObjCPass which needs to add
new references. The method is virtual because we may add references to
different data structures depending on whether we parsed a macho file or
yaml.
llvm-svn: 259436
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we parse a MachoFile, we set a number of members from the parsed
file, for example, subsectionsViaSymbols.
However, a number of passes, such as ObjCPass, create local copies of
MachoFile and don't get the benefit of setting flags and other fields in
the parser. Instead we can just give a more sensible default as the parser
will definitely get the correct value from the file anyway.
llvm-svn: 259426
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that MachoFile has classof(), we can use dyn_cast instead which
is actually the only safe way to handle this.
Turns out this actually manifests as a bug as we were incorrectly
casting instances which weren't MachoFile in to a MachoFile.
Unfortunately, there's no reliable way of checking for this as it
requires that the file we are looking for has a 0 at exactly the byte
we need for the load of subsectionsViaSymbols.
llvm-svn: 259413
|
|
|
|
|
|
|
|
|
| |
__DATA, __objc_catlist contains a list of pointers to categories.
We want to atomize it so that the ObjC pass can later optimize and remove
categories. That will be a later patch.
llvm-svn: 259386
|