aboutsummaryrefslogtreecommitdiff
path: root/libjava/java/util/Collections$CheckedMap$CheckedEntrySet.h
AgeCommit message (Expand)AuthorFilesLines
2007-01-09Merged gcj-eclipse branch to trunk.Tom Tromey1-0/+27
generated by cgit v1.1 at 2026-02-11 10:13:03 +0000
s Unnamed repository; edit this file 'description' to name the repository.root
aboutsummaryrefslogtreecommitdiff
path: root/lld/test/mach-o
AgeCommit message (Collapse)AuthorFilesLines
2021-07-15[test] Avoid llvm-nm one-dash long optionsFangrui Song1-1/+1
2021-03-01[lld-macho] Switch default to new Darwin backendJez Ng130-206/+206
The new Darwin backend for LLD is now able to link reasonably large real-world programs on x86_64. For instance, we have achieved self-hosting for the X86_64 target, where all LLD tests pass when building lld with itself on macOS. As such, we would like to make it the default back-end. The new port is now named `ld64.lld`, and the old port remains accessible as `ld64.lld.darwinold` This [annoucement email][1] has some context. (But note that, unlike what the email says, we are no longer doing this as part of the LLVM 12 branch cut -- instead we will go into LLVM 13.) Numerous mechanical test changes were required to make this change; in the interest of creating something that's reviewable on Phabricator, I've split out the boring changes into a separate diff (D95905). I plan to merge its contents with those in this diff before landing. (@gkm made the original draft of this diff, and he has agreed to let me take over.) [1]: https://lists.llvm.org/pipermail/llvm-dev/2021-January/147665.html Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D95204
2020-11-18Reland "[lib/Support/YAMLTraits] - Don't print leading zeroes when dumping ↵Georgii Rymar1-3/+3
Hex8/Hex16/Hex32 types." (https://reviews.llvm.org/D90930). This reverts reverting commit fc40a03323a4b265ccbed34a07e281b13c5e8367 and fixes LLD (MachO/wasm) tests that failed previously.
2020-09-04[lld] Test corrections after 3f1a9b7eca0 added segment names to objdump outputDaniel Sanders2-3/+3
2020-07-02ld64.lld: Make janky support for tbd files actually work sometimesNico Weber1-3/+3
Also fix a bug in the test input that made the test miss this issue.
2020-07-02ld64.lld: Add janky support for tbd filesNico Weber2-0/+63
With this, a simple hello world links against libSystem.tbd and the old ld64.lld linker kind of works again with newer SDKs. The motivation here is to have an arm64 cross linker that's good enough to be able to run simple configure link checks on non-mac systems for generating config.h files. Once -flavor darwinnew can link arm64, we'll switch to that.
2020-04-29Reland D78837 [lld] Remove special cases from default ld driver mode.Fangrui Song2-38/+0
Drops the behavior from rL217112. Use the Gnu driver mode by default for all platforms when ld is invoked. Other names for the program (such as link or ld64) continue working as before. Reviewed By: MaskRay, srhines, smeenai, ruiu Differential Revision: https://reviews.llvm.org/D78837
2020-04-02[lld] NFC: fix trivial typos in commentsKazuaki Ishizaki2-2/+2
Differential Revision: https://reviews.llvm.org/D72339
2020-03-15[test] lld/test/: change llvm-objdump single-dash long options to ↵Fangrui Song32-65/+65
double-dash options
2019-10-30[LLD] - Fix a test after obj2yaml change.Georgii Rymar1-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.
2019-09-26[lld][mach-o] Avoid segfaulting when handling an empty section list.Matt Davis1-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
2019-05-01[test] Change llvm-readobj -long-option to --long-option or well-known short ↵Fangrui Song8-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
2019-04-17lld: Fix initial Mach-O load commands size calculation omitting ↵Rui Ueyama1-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
2019-04-16[MachO] Add -macho to llvm-objdump commandsFangrui Song4-4/+4
llvm-svn: 358473
2018-10-12Make YAML quote forward slashes.Zachary Turner4-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
2018-10-12Revert "Make YAML quote forward slashes."Zachary Turner4-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
2018-10-12Make YAML quote forward slashes.Zachary Turner4-7/+7
llvm-svn: 344357
2018-08-06[lit, python] Always add quotes around the python path in litStella Stamenova1-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
2018-02-21[lit] Fix a problem with spaces in the python path by adding quotes around itAaron Smith1-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
2018-02-16Replace -flavor {gnu,darwin} with ld64.lld or ld.lld.Rui Ueyama127-203/+203
llvm-svn: 325390
2017-08-24[MACH-O] Fix the ASM code generated for __stub_helpers sectionRui Ueyama1-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
2017-06-19Fix lld test that was causing llvm-clang-lld-x86_64-scei-ps4-ubuntu-fastKevin Enderby1-2/+2
to fail due to change in llvm trunk r305744. llvm-svn: 305747
2016-11-15Partially revert r287009: Remove trailing whitespace.Rui Ueyama2-0/+0
This reverts part of r287009 because I accidentally changed binary files. llvm-svn: 287010
2016-11-15Remove trailing whitespace.Rui Ueyama2-0/+0
llvm-svn: 287009
2016-10-05Remove trailing whitespace.Rui Ueyama12-212/+212
llvm-svn: 283372
2016-09-12[CMake] Fix linker-as-ld to symlink instead of copy lldChris Bieneman1-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
2016-08-11Dead strip DESC bits should only be set on object files.Pete Cooper1-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
2016-08-11Better compress lazy binding info to match ld64.Pete Cooper1-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
2016-08-11Generate slightly more compressed binding opcodes when entries are the same ↵Pete Cooper1-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
2016-08-11Add test for rebase opcodes. We didn't have one. NFC.Pete Cooper1-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
2016-08-11Add missing RUN line from r278398. This test works with this line but i ↵Pete Cooper1-0/+1
forgot to push it llvm-svn: 278399
2016-08-11Arm64 stubs alignment is 2, not 4.Pete Cooper1-0/+7
This matches the behaviour of ld64 when looking at the alignment of the stubs section in the final image. llvm-svn: 278398
2016-08-11Change when we choose to add an LC_LOAD_DYLIB to the final image.Pete Cooper1-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
2016-08-11Change all the libSystem test files to be dylibs instead of normalized ↵Pete Cooper4-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
2016-08-11Fix one more test missed by r278372. The next commit will update libsystem ↵Pete Cooper1-1/+1
in a way which broke without this fix as it referenced the wrong file llvm-svn: 278385
2016-08-11Fix off-by-one error in default currentVersion.Pete Cooper1-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
2016-08-11Have one version of libSystem for each arch. NFC.Pete Cooper48-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
2016-08-10[lld][MachO] Fix LC_SEGEMENT[_64] filesize computation in -r mode.Lang Hames1-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
2016-08-08The first string table entry should be a null terminated space, not just null.Pete Cooper1-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
2016-08-05ExportTrie nodes need to be visisted in order.Pete Cooper1-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
2016-07-28Trying to fix this test on windows.Rafael Espindola1-1/+1
llvm-svn: 277022
2016-07-28[lld][MachO] Fix bugs in the debug-syms test case.Lang Hames1-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
2016-07-27[lld][MachO] Re-apply r276921 with fix - initialize strings for debug stringLang Hames1-0/+249
copies. llvm-svn: 276935
2016-07-27[lld][MachO] Temporarily revert r276921 - it's causing bot-failures on Linux.Lang Hames1-249/+0
llvm-svn: 276928
2016-07-27[lld][MachO] Add debug info support for MachO.Lang Hames1-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
2016-06-25[lld][MachO] Add support for x86-64 negDelta64 references and fix negDelta32.Lang Hames1-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
2016-03-24Parsed alignment should be a power of 2.Pete Cooper12-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
2016-03-15Fix EHFrame processing to add implicit references when needed.Pete Cooper2-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
2016-02-09Use __nl_symbol_ptr instead of __got in the stubs pass on x86 archs.Pete Cooper1-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
2016-02-09Aligned __stub_helper section to 4-bytes.Pete Cooper1-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
generated by cgit v1.1 at 2026-02-11 10:13:02 +0000