| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
Previously the alignment of the .bss section was not
properly set because of a bug in AtomizeDefinedSymbolsInSection.
We set the alignment of the section at the end of the function,
but we use an eraly return for the .bss section, so the code had
been skipped.
llvm-svn: 212571
|
|
|
|
| |
llvm-svn: 212407
|
|
|
|
| |
llvm-svn: 212372
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dynamic symbol table populating and DT_NEEDED tag creation.
The `isDynSymEntryRequired` function returns true if the specified shared
library atom requires a dynamic symbol table entry. The `isNeededTagRequired`
function returns true if we need to create DT_NEEDED tag for the shared
library defined specified shared atom.
By default the both functions return true. So there is no functional changes
for all targets except MIPS. Probably we need to spread the same modifications
on other ELF targets but I want to implement and fully tested complete set of
changes for MIPS target first.
For MIPS we create a dynamic symbol table entry for a shared library atom iif
this atom is referenced by a regular defined atom. For example, if library L1
defines symbol T1, library L2 defines symbol T2 and uses symbol T1
and executable file E1 uses symbol T2 but does not use symbol T1 we create
an entry in the E1 dynamic symbol table for symbol T2 and do not create
an entry for T1.
The patch creates DT_NEEDED tags for shared libraries contain shared library
atoms which a) referenced by regular defined atoms; b) have corresponding
copy dynamic relocations (R_MIPS_COPY).
Now the patch does not take in account --as-needed / --no-as-needed command
line options. So it is too restrictive and create DT_NEEDED tags for really
needed shared libraries only. I plan to fix that by subsequent patches.
llvm-svn: 211674
|
|
|
|
| |
llvm-svn: 211596
|
|
|
|
| |
llvm-svn: 211548
|
|
|
|
|
|
| |
No functional changes.
llvm-svn: 211431
|
|
|
|
|
|
| |
A refactoring, with the added benefit of helping OS X builds.
llvm-svn: 211371
|
|
|
|
| |
llvm-svn: 211367
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
COFF supports a feature similar to ELF's section groups. This
patch implements it.
In ELF, section groups are identified by their names, and they are
treated somewhat differently from regular symbols. In COFF, the
feature is realized in a more straightforward way. A section can
have an annotation saying "if Nth section is linked, link this
section too."
I added a new reference type, kindAssociate. If a target atom is
coalesced away, the referring atom is removed by Resolver, so that
they are treated as a group.
Differential Revision: http://reviews.llvm.org/D4028
llvm-svn: 211106
|
|
|
|
| |
llvm-svn: 211034
|
|
|
|
|
|
| |
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: 210878
|
|
|
|
| |
llvm-svn: 210831
|
|
|
|
| |
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
|
|
|
|
|
|
| |
We have to look for both std::make_error_code as well as our overloads.
llvm-svn: 210704
|
|
|
|
|
|
| |
This is an update for a llvm api change.
llvm-svn: 210689
|
|
|
|
|
|
| |
does not get an entry in the dynamic symbol table.
llvm-svn: 210648
|
|
|
|
|
|
|
|
|
| |
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: 210621
|
|
|
|
| |
llvm-svn: 210612
|
|
|
|
|
|
| |
No functional changes.
llvm-svn: 210532
|
|
|
|
|
|
| |
No functional changes.
llvm-svn: 210531
|
|
|
|
|
|
|
| |
In -r mode the sections use the table used to parse .o files. Otherwise
use final exectuable table. No functionality change.
llvm-svn: 210506
|