summaryrefslogtreecommitdiffstats
path: root/lld/test/mach-o
Commit message (Collapse)AuthorAgeFilesLines
* [LLD] - Fix a test after obj2yaml change.Georgii Rymar2019-10-301-6/+3
| | | | | I am not sure why obj2yaml is used to check the linkers output, but anyways, the format was changed in https://reviews.llvm.org/rG6e779e953e9d.
* [lld][mach-o] Avoid segfaulting when handling an empty section list.Matt Davis2019-09-261-0/+9
| | | | | | | | | | | | | | | | | 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
* [test] Change llvm-readobj -long-option to --long-option or well-known short ↵Fangrui Song2019-05-018-8/+8
| | | | | | | | | | | | options. NFC Also change some options that have different semantics (cause confusion) in llvm-readelf mode: -s => -S -t => --symbols -sd => --section-data llvm-svn: 359651
* lld: Fix initial Mach-O load commands size calculation omitting ↵Rui Ueyama2019-04-171-0/+305
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [MachO] Add -macho to llvm-objdump commandsFangrui Song2019-04-164-4/+4
| | | | llvm-svn: 358473
* Make YAML quote forward slashes.Zachary Turner2018-10-124-7/+7
| | | | | | | | | | | | | | | | | If you have the string /usr/bin, prior to this patch it would not be quoted by our YAML serializer. But a string like C:\src would be, due to the presence of a backslash. This makes the quoting rules of basically every single file path different depending on the path syntax (posix vs. Windows). While technically not required by the YAML specification to quote forward slashes, when the behavior of paths is inconsistent it makes it difficult to portably write FileCheck lines that will work with either kind of path. Differential Revision: https://reviews.llvm.org/D53169 llvm-svn: 344359
* Revert "Make YAML quote forward slashes."Zachary Turner2018-10-124-7/+7
| | | | | | | | | | This reverts commit b86c16ad8c97dadc1f529da72a5bb74e9eaed344. This is being reverted because I forgot to write a useful commit message, so I'm going to resubmit it with an actual commit message. llvm-svn: 344358
* Make YAML quote forward slashes.Zachary Turner2018-10-124-7/+7
| | | | llvm-svn: 344357
* [lit, python] Always add quotes around the python path in litStella Stamenova2018-08-061-1/+1
| | | | | | | | | | | | | | | Summary: The issue with the python path is that the path to python on Windows can contain spaces. To make the tests always work, the path to python needs to be surrounded by quotes. This is a companion change to: https://reviews.llvm.org/D50206 Reviewers: asmith, zturner, espindola Subscribers: emaste, sbc100, arichardson, aheejin, steven_wu, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D50282 llvm-svn: 339075
* [lit] Fix a problem with spaces in the python path by adding quotes around itAaron Smith2018-02-211-1/+1
| | | | | | | | | | | | | | | | Summary: This fixes two failing tests on Windows with an installed version of python that has spaces in the path. * elf/lto/cache.ll * mach-o/dependency_info.yaml Reviewers: zturner, llvm-commits, stella.stamenova Subscribers: emaste, arichardson Differential Revision: https://reviews.llvm.org/D43265 llvm-svn: 325650
* Replace -flavor {gnu,darwin} with ld64.lld or ld.lld.Rui Ueyama2018-02-16127-203/+203
| | | | llvm-svn: 325390
* [MACH-O] Fix the ASM code generated for __stub_helpers sectionRui Ueyama2017-08-241-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix lld test that was causing llvm-clang-lld-x86_64-scei-ps4-ubuntu-fastKevin Enderby2017-06-191-2/+2
| | | | | | to fail due to change in llvm trunk r305744. llvm-svn: 305747
* Partially revert r287009: Remove trailing whitespace.Rui Ueyama2016-11-152-0/+0
| | | | | | This reverts part of r287009 because I accidentally changed binary files. llvm-svn: 287010
* Remove trailing whitespace.Rui Ueyama2016-11-152-0/+0
| | | | llvm-svn: 287009
* Remove trailing whitespace.Rui Ueyama2016-10-0512-212/+212
| | | | llvm-svn: 283372
* [CMake] Fix linker-as-ld to symlink instead of copy lldChris Bieneman2016-09-121-2/+2
| | | | | | | | | | | | Summary: This test fails if you're building with BUILD_SHARED_LIBS because the LLVM libraries are found via @rpath. Symlinking instead of copying should be sufficiently robust for the test case. Reviewers: llvm-commits Subscribers: davide Differential Revision: https://reviews.llvm.org/D24476 llvm-svn: 281271
* Dead strip DESC bits should only be set on object files.Pete Cooper2016-08-111-0/+4
| | | | | | It only makes sense to set on N_NO_DEAD_STRIP on a relocatable object file. Otherwise the bits aren't useful for anything. Matches the ld64 behaviour. llvm-svn: 278419
* Better compress lazy binding info to match ld64.Pete Cooper2016-08-111-12/+0
| | | | | | | | | 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
* Generate slightly more compressed binding opcodes when entries are the same ↵Pete Cooper2016-08-111-14/+8
| | | | | | | | | | | | 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
* Add test for rebase opcodes. We didn't have one. NFC.Pete Cooper2016-08-111-0/+161
| | | | | | | This will be used to test upcoming changes to improve binding opcode emission to match the more compressed form ld64 can generate. llvm-svn: 278400
* Add missing RUN line from r278398. This test works with this line but i ↵Pete Cooper2016-08-111-0/+1
| | | | | | forgot to push it llvm-svn: 278399
* Arm64 stubs alignment is 2, not 4.Pete Cooper2016-08-111-0/+7
| | | | | | This matches the behaviour of ld64 when looking at the alignment of the stubs section in the final image. llvm-svn: 278398
* Change when we choose to add an LC_LOAD_DYLIB to the final image.Pete Cooper2016-08-111-0/+39
| | | | | | | | | | | Currently we do this when an atom is used, but we need to do it when a dylib is referenced on the cmdline as this matches ld64. This fixes much confusion over which maps are indexed with installName vs path. There is likely other confusion so i'll be seeing if i can remove path() completely in a future commit as path() shouldn't really be needed by anyone. llvm-svn: 278396
* Change all the libSystem test files to be dylibs instead of normalized ↵Pete Cooper2016-08-114-20/+24
| | | | | | | | | | | | | files. Currently NFC. A future commit will change when we choose to add an LC_LOAD_DYLIB to the final image. Currently we do this when an atom is used, but we need to do it when a dylib is referenced on the cmdline as this matches ld64. To allow this change, libsystem (and other future yaml files representing dylibs) need to be dylibs so that the loader can see to add them to the referenced dylib list. llvm-svn: 278386
* Fix one more test missed by r278372. The next commit will update libsystem ↵Pete Cooper2016-08-111-1/+1
| | | | | | in a way which broke without this fix as it referenced the wrong file llvm-svn: 278385
* Fix off-by-one error in default currentVersion.Pete Cooper2016-08-111-2/+2
| | | | | | | | A version of 0x1000 is 0.16.0, not 1.0.0 as the comment said. Fix the value to match the comment, and also the one test case which had this wrong. llvm-svn: 278381
* Have one version of libSystem for each arch. NFC.Pete Cooper2016-08-1148-80/+115
| | | | | | | | | | | | | | | An upcoming commit will change how we choose to reference a dylib. Currently dylibs are only given an LC_LOAD_DYLIB in the final image if an atom is used. This is different from ld64 which adds the load command when the dylib is referenced on the cmdline. In order to change this behaviour, we need libSystem.yaml to actually contain a mach header so that it is parsed as a dylib, instead of currently being parsed as a normalised file. To get a mach header, we also require an arch, so now we have one libsystem per arch and all the tests have been updated to choose the correct one. llvm-svn: 278372
* [lld][MachO] Fix LC_SEGEMENT[_64] filesize computation in -r mode.Lang Hames2016-08-101-0/+31
| | | | | | | | | | 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
* The first string table entry should be a null terminated space, not just null.Pete Cooper2016-08-081-0/+66
| | | | | | | 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
* ExportTrie nodes need to be visisted in order.Pete Cooper2016-08-051-0/+62
| | | | | | | | 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
* Trying to fix this test on windows.Rafael Espindola2016-07-281-1/+1
| | | | llvm-svn: 277022
* [lld][MachO] Fix bugs in the debug-syms test case.Lang Hames2016-07-281-3/+3
| | | | | | | The previous run line depended on libSystem.dylib being present, which it's not on non-darwin platforms. The new run line uses libSystem.yaml instead. llvm-svn: 276999
* [lld][MachO] Re-apply r276921 with fix - initialize strings for debug stringLang Hames2016-07-271-0/+249
| | | | | | copies. llvm-svn: 276935
* [lld][MachO] Temporarily revert r276921 - it's causing bot-failures on Linux.Lang Hames2016-07-271-249/+0
| | | | llvm-svn: 276928
* [lld][MachO] Add debug info support for MachO.Lang Hames2016-07-271-0/+249
| | | | | | | | | 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
* [lld][MachO] Add support for x86-64 negDelta64 references and fix negDelta32.Lang Hames2016-06-251-40/+85
| | | | | | | | | | These references are used to implement MachO/x64-64 subtractor relocations where the minuend is being fixed up, rather than the subtrahend. The 64-bit version was not previously supported, the 32-bit version was partially implemented but contained bugs not caught by existing test cases. This patch fixes both functionality and test coverage. llvm-svn: 273759
* Parsed alignment should be a power of 2.Pete Cooper2016-03-2412-14/+14
| | | | | | | | | | The .o path always makes sure to store a power of 2 value in the Section alignment. However, the YAML code didn't verify this. Added verification and updated all the tests which had a 3 but meant to have 2^3. llvm-svn: 264228
* Fix EHFrame processing to add implicit references when needed.Pete Cooper2016-03-152-4/+322
| | | | | | | | | | | | | | | | | 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
* Use __nl_symbol_ptr instead of __got in the stubs pass on x86 archs.Pete Cooper2016-02-091-0/+4
| | | | | | | | | | 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
* Aligned __stub_helper section to 4-bytes.Pete Cooper2016-02-091-0/+7
| | | | | | | | | | | | 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
* lld/test/mach-o/dependency_info.yaml: Forgot to remove XFAIL:win32.NAKAMURA Takumi2016-02-091-5/+0
| | | | llvm-svn: 260209
* lld/test/mach-o/dependency_info.yaml: Tweak for dos path.NAKAMURA Takumi2016-02-091-3/+3
| | | | llvm-svn: 260208
* check-lld: Introduce %python.NAKAMURA Takumi2016-02-091-1/+1
| | | | llvm-svn: 260207
* Add cmdline options for LC_DATA_IN_CODE load command.Pete Cooper2016-02-091-0/+35
| | | | | | | | | | | | 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
* Generate LC_FUNCTION_STARTS load command.Pete Cooper2016-02-091-0/+32
| | | | | | | | | | | | | | 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
* We should never dead strip mach header symbols.Pete Cooper2016-02-091-3/+4
| | | | | | | | 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
* Set max segment protection level.Pete Cooper2016-02-062-0/+156
| | | | | | | | | | | 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
* Set CPU_SUBTYPE_LIB64 in mach_header.Pete Cooper2016-02-041-0/+34
| | | | | | | | | | | 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
* Add test missed from r259746Pete Cooper2016-02-041-0/+28
| | | | llvm-svn: 259747
OpenPOWER on IntegriCloud