Patch by Patricio Villalobos.
I discovered that lld for darwin is generating the wrong code for lazy
bindings in the __stub_helper section (at least for osx 10.12). This is
the way i can reproduce this problem, using this program:
#include <stdio.h>
int main(int argc, char **argv) {
printf("C: printf!\n");
puts("C: puts!\n");
return 0;
}
Then I link it using i have tested it in 3.9, 4.0 and 4.1 versions:
$ clang -c hello.c
$ lld -flavor darwin hello.o -o h1 -lc
When i execute the binary h1 the system gives me the following error:
C: printf!
dyld: lazy symbol binding failed:
BIND_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB
has segment 4 which is too large (0..3)
dyld: BIND_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB has segment 4 which is too
large (0..3)
Trace/BPT trap: 5
Investigating the code, it seems that the problem is that the asm code
generated in the file StubPass.cpp, specifically in the line 323,when it
adds, what it seems an arbitrary number (12) to the offset into the lazy
bind opcodes section, but it should be calculated depending on the
MachONormalizedFileBinaryWrite::lazyBindingInfo result.
I confirmed this bug by patching the code manually in the binary and
writing the right offset in the asm code (__stub_helper).
This patch fixes the content of the atom that contains the assembly code
when the offset is known.
Differential Revision: https://reviews.llvm.org/D35387
llvm-svn: 311734
Adds a GenericError class to lld/Core which can carry a string. This is
analygous to the dynamic_error we currently use in lld/Core.
Use this GenericError instead of make_dynamic_error_code. Also, provide
an implemention of GenericError::convertToErrorCode which for now converts
it in to the dynamic_error_code we used to have. This will go away once
all the APIs are converted.
llvm-svn: 264910
We were casting a potentially unaligned pointer to uint32_t and
dereferencing. As the pointer ultimately comes from the object file,
there's no way to guarantee alignment, so use the little32_t read instead.
Also, little32_t knows about endianness, so in theory this may have broken on
big endian machines.
llvm-svn: 264231
The size of a section can be zero, even when it contains atoms, so
long as all of the atoms are also size 0. In this case we were
allocating space for a 0 sized buffer.
Changed this to only allocate when we need the space, but also cleaned
up all the code to use MutableArrayRef instead of uint8_t* so its much much
safer as we get bounds checking on all of our section creation logic.
llvm-svn: 264204
The current code for processCIE and processFDE returns out if it sees
any references. The problem with this is that some references could be
explicit in the binary, while others are implicit as they can be
inferred from the content of the EHFrame itself.
This change walks the references we have against the references we
need, and verifies that all explicit references are in the correct place,
and generates any missing implicit ones.
Reviewed by Lang Hames and Nick Kledzik.
Differential Revision: http://reviews.llvm.org/D15439
llvm-svn: 263590
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
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
The fixup content we encode here should be the offset from the
fixup location back to the last nonlocal label. We were only encoding
the address of the fixup, and not taking in to account the base address
of the atom we are in.
Updated the test case here to have a text section which will come before
the data section where the relocation lives. .data being at offset 0 had
previously been hiding this bug.
llvm-svn: 256974
negDelta32 is only ever implicitly generated as the FDE->CIE reference.
We therefore don't emit a relocation for it in the object file in -r mode.
The value we write in to the FDE location therefore needs to point to the
final target address of the CIE, and not the inAtomAddress as it was currently
doing.
llvm-svn: 255835
The delta64 relocation is represented as the pair ARM64_RELOC_SUBTRACTOR and ARM64_RELOC_UNSIGNED.
Those should always have the same offset, so this adds a check and tests to ensure this is the case.
Also updated the error printing in this case to shows both relocs when erroring on pair.
llvm-svn: 255274
The gcc_except_tab was generating these references to point to the typeinfo in the data section.
gcc_except_tab also had the DW_EH_PE_indirect flag set which means that at runtime we are going
to dereference this entry as if it is in the GOT.
Reviewed by Nick Kledzik in http://reviews.llvm.org/D15360.
llvm-svn: 255085
The function took either StringRef or Twine. Since string literals are
ambiguous when resolving the overloading, many code calls used this
function with explicit type conversion. That led awkward code like
make_dynamic_error_code(Twine("Error occurred")).
This patch adds a function definition for string literals, so that
you can directly call the function with literals.
llvm-svn: 234841
This is just a mechanical cleanup, no functionality changed. This just
fixes very minor inconsistencies with how #include lines were spaced and
sorted in LLD.
llvm-svn: 225978
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
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
All compiler generated mach-o object files are marked with MH_SUBSECTIONS_VIA_SYMBOLS.
But hand written assembly files need to opt-in if they are written correctly.
The flag means the linker can break up a sections at symbol addresses and
dead strip or re-order functions.
This change recognizes object files without the flag and marks its atoms as
not dead strippable and adds a layout-after chain of references so that the
atoms cannot be re-ordered.
llvm-svn: 220348
Not all situations are representable in the compressed __unwind_info format,
and when this happens the entry needs to point to the more general __eh_frame
description.
Just x86_64 implementation for now.
rdar://problem/18208653
llvm-svn: 219836
We'll also need references back to the CIE eventually, but for now making sure
we can work out what an FDE is referring to is enough.
The actual kind of reference needs to be different between architectures,
probably because of MachO's chronic shortage of relocation types but I don't
really want to know in case I find out something that distresses me even more.
rdar://problem/18208653
llvm-svn: 219824
Arm code has two instruction encodings "thumb" and "arm". When branching from
one code encoding to another, you need to use an instruction that switches
the instruction mode. Usually the transition only happens at call sites, and
the linker can transform a BL instruction in BLX (or vice versa). But if the
compiler did a tail call optimization and a function ends with a branch (not
branch and link), there is no pc-rel BX instruction.
The ShimPass looks for pc-rel B instructions that will need to switch mode.
For those cases it synthesizes a shim which does the transition, then modifies
the original atom with the B instruction to target to the shim atom.
llvm-svn: 219655
This is a minimally useful pass to construct the __unwind_info section in a
final object from the various __compact_unwind inputs. Currently it doesn't
produce any compressed pages, only works for x86_64 and will fail if any
function ends up without __compact_unwind.
rdar://problem/18208653
llvm-svn: 218703
Most of the changes are in the new file ArchHandler_arm64.cpp. But a few
things had to be fixed to support 16KB pages (instead of 4KB) which iOS arm64
requires. In addition the StubInfo struct had to be expanded because
arm64 uses two instruction (ADRP/LDR) to load a global which requires two
relocations. The other mach-o arches just needed one relocation.
llvm-svn: 217469
Rui Ueyama