maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/mach-o/dylib-install-names.yaml

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

75 lines
3.0 KiB
YAML
Raw Normal View History

[mach-o]: make the default dylib install-name the output filename. llvm-svn: 212094
2014-07-01 16:41:45 +08:00
# Check we accept -install_name correctly:
Replace -flavor {gnu,darwin} with ld64.lld or ld.lld. llvm-svn: 325390
2018-02-17 05:16:57 +08:00
# RUN: ld64.lld -arch x86_64 -install_name libwibble.dylib -dylib \
[mach-o] propagate dylib version numbers Mach-o does not use a simple SO_NEEDED to track dependent dylibs. Instead, the linker copies four things from each dylib to each client: the runtime path (aka "install name"), the build time, current version (dylib build number), and compatibility version The build time is no longer used (it cause every rebuild of a dylib to be different). The compatibility version is usually just 1.0 and never changes, or the dylib becomes incompatible. This patch copies that information into the NormalizedMachO format and propagates it to clients. llvm-svn: 222300
2014-11-19 10:21:53 +08:00
# RUN: -compatibility_version 2.0 -current_version 5.3 \
Have one version of libSystem for each arch. NFC. 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-12 02:08:59 +08:00
# RUN: %p/Inputs/x86_64/libSystem.yaml %s -o %t.dylib
[test] lld/test/: change llvm-objdump single-dash long options to double-dash options
2020-03-16 08:47:44 +08:00
# RUN: llvm-objdump --private-headers %t.dylib | FileCheck %s --check-prefix=CHECK-BINARY-WRITE
[mach-o]: make the default dylib install-name the output filename. llvm-svn: 212094
2014-07-01 16:41:45 +08:00
# Check we read LC_ID_DYLIB correctly:
Replace -flavor {gnu,darwin} with ld64.lld or ld.lld. llvm-svn: 325390
2018-02-17 05:16:57 +08:00
# RUN: ld64.lld -arch x86_64 %p/Inputs/use-dylib-install-names.yaml \
Have one version of libSystem for each arch. NFC. 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-12 02:08:59 +08:00
# RUN: %p/Inputs/x86_64/libSystem.yaml %t.dylib -dylib -o %t2.dylib
[test] lld/test/: change llvm-objdump single-dash long options to double-dash options
2020-03-16 08:47:44 +08:00
# RUN: llvm-objdump --private-headers %t2.dylib | FileCheck %s --check-prefix=CHECK-BINARY-READ
[mach-o] add representation for LC_ID_DYLIB to MachONormalizedFile It still needs to be tied into BinaryReader, but this allows reasonably sensible creation of SharedLibrary atoms on MachO. llvm-svn: 212093
2014-07-01 16:15:41 +08:00
[mach-o]: make the default dylib install-name the output filename. llvm-svn: 212094
2014-07-01 16:41:45 +08:00
# Check we default the install-name to the output file:
Replace -flavor {gnu,darwin} with ld64.lld or ld.lld. llvm-svn: 325390
2018-02-17 05:16:57 +08:00
# RUN: ld64.lld -arch x86_64 -dylib %s -o libwibble.dylib \
[mach-o] propagate dylib version numbers Mach-o does not use a simple SO_NEEDED to track dependent dylibs. Instead, the linker copies four things from each dylib to each client: the runtime path (aka "install name"), the build time, current version (dylib build number), and compatibility version The build time is no longer used (it cause every rebuild of a dylib to be different). The compatibility version is usually just 1.0 and never changes, or the dylib becomes incompatible. This patch copies that information into the NormalizedMachO format and propagates it to clients. llvm-svn: 222300
2014-11-19 10:21:53 +08:00
# RUN: -compatibility_version 2.0 -current_version 5.3 \
Have one version of libSystem for each arch. NFC. 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-12 02:08:59 +08:00
# RUN: %p/Inputs/x86_64/libSystem.yaml
[test] lld/test/: change llvm-objdump single-dash long options to double-dash options
2020-03-16 08:47:44 +08:00
# RUN: llvm-objdump --private-headers libwibble.dylib | FileCheck %s --check-prefix=CHECK-BINARY-WRITE
[mach-o]: make the default dylib install-name the output filename. llvm-svn: 212094
2014-07-01 16:41:45 +08:00
# RUN: rm -f libwibble.dylib
[mach-o] add testing coverage for -single_module llvm-svn: 217412
2014-09-09 10:20:34 +08:00
# Check -single_module does nothing
Replace -flavor {gnu,darwin} with ld64.lld or ld.lld. llvm-svn: 325390
2018-02-17 05:16:57 +08:00
# RUN: ld64.lld -arch x86_64 -dylib %s -install_name libwibble.dylib \
[mach-o] propagate dylib version numbers Mach-o does not use a simple SO_NEEDED to track dependent dylibs. Instead, the linker copies four things from each dylib to each client: the runtime path (aka "install name"), the build time, current version (dylib build number), and compatibility version The build time is no longer used (it cause every rebuild of a dylib to be different). The compatibility version is usually just 1.0 and never changes, or the dylib becomes incompatible. This patch copies that information into the NormalizedMachO format and propagates it to clients. llvm-svn: 222300
2014-11-19 10:21:53 +08:00
# RUN: -compatibility_version 2.0 -current_version 5.3 \
Have one version of libSystem for each arch. NFC. 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-12 02:08:59 +08:00
# RUN: -single_module -o %t2.dylib %p/Inputs/x86_64/libSystem.yaml
[test] lld/test/: change llvm-objdump single-dash long options to double-dash options
2020-03-16 08:47:44 +08:00
# RUN: llvm-objdump --private-headers %t2.dylib | FileCheck %s --check-prefix=CHECK-BINARY-WRITE
[mach-o] add testing coverage for -single_module llvm-svn: 217412
2014-09-09 10:20:34 +08:00
[mach-o] add representation for LC_ID_DYLIB to MachONormalizedFile It still needs to be tied into BinaryReader, but this allows reasonably sensible creation of SharedLibrary atoms on MachO. llvm-svn: 212093
2014-07-01 16:15:41 +08:00
--- !mach-o
arch: x86_64
file-type: MH_OBJECT
flags: [ MH_SUBSECTIONS_VIA_SYMBOLS ]
has-UUID: false
OS: unknown
sections:
- segment: __TEXT
section: __text
type: S_REGULAR
attributes: [ S_ATTR_PURE_INSTRUCTIONS, S_ATTR_SOME_INSTRUCTIONS ]
alignment: 4
address: 0x0000000000000000
content: [ 0xCC, 0xC3, 0x90, 0xC3, 0x90, 0x90, 0xC3, 0x90,
0x90, 0x90, 0xC3, 0x90, 0x90, 0x90, 0x90, 0xC3,
0x31, 0xC0, 0xC3 ]
local-symbols:
- name: _myStatic
type: N_SECT
sect: 1
value: 0x000000000000000B
global-symbols:
- name: _myGlobal
type: N_SECT
scope: [ N_EXT ]
sect: 1
value: 0x0000000000000001
...
[macho] Minor install_name fixes Summary: Fix the binary file reader to properly read dyld version info. Update the install_name test case to properly test the binary reader. We can't use '-print_atoms' as the output format is 'native' yaml and it does not contains the dyld current and compatibility versions. Also change the timestamp value of LD_ID_DYLD to match the one generated by ld64. The dynamic linker (dyld) used to expects different values for timestamp in LD_ID_DYLD and LD_LOAD_DYLD for prebound images. While prebinding is deprecated, we should probably keep it safe and match ld64. Reviewers: kledzik Subscribers: llvm-commits Projects: #lld Differential Revision: http://reviews.llvm.org/D6736 llvm-svn: 224681
2014-12-20 17:22:56 +08:00
# CHECK-BINARY-WRITE: cmd LC_ID_DYLIB
# CHECK-BINARY-WRITE-NEXT: cmdsize 40
# CHECK-BINARY-WRITE-NEXT: name libwibble.dylib (offset 24)
# CHECK-BINARY-WRITE-NEXT: time stamp 1
# CHECK-BINARY-WRITE-NEXT: current version 5.3.0
# CHECK-BINARY-WRITE-NEXT: compatibility version 2.0.0
[mach-o] add representation for LC_ID_DYLIB to MachONormalizedFile It still needs to be tied into BinaryReader, but this allows reasonably sensible creation of SharedLibrary atoms on MachO. llvm-svn: 212093
2014-07-01 16:15:41 +08:00
[macho] Minor install_name fixes Summary: Fix the binary file reader to properly read dyld version info. Update the install_name test case to properly test the binary reader. We can't use '-print_atoms' as the output format is 'native' yaml and it does not contains the dyld current and compatibility versions. Also change the timestamp value of LD_ID_DYLD to match the one generated by ld64. The dynamic linker (dyld) used to expects different values for timestamp in LD_ID_DYLD and LD_LOAD_DYLD for prebound images. While prebinding is deprecated, we should probably keep it safe and match ld64. Reviewers: kledzik Subscribers: llvm-commits Projects: #lld Differential Revision: http://reviews.llvm.org/D6736 llvm-svn: 224681
2014-12-20 17:22:56 +08:00
# CHECK-BINARY-READ: cmd LC_LOAD_DYLIB
# CHECK-BINARY-READ-NEXT: cmdsize 56
# CHECK-BINARY-READ-NEXT: name /usr/lib/libSystem.B.dylib (offset 24)
# CHECK-BINARY-READ-NEXT: time stamp 2
Fix off-by-one error in default currentVersion. 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-12 02:41:14 +08:00
# CHECK-BINARY-READ-NEXT: current version 1.0.0
# CHECK-BINARY-READ-NEXT: compatibility version 1.0.0
[macho] Minor install_name fixes Summary: Fix the binary file reader to properly read dyld version info. Update the install_name test case to properly test the binary reader. We can't use '-print_atoms' as the output format is 'native' yaml and it does not contains the dyld current and compatibility versions. Also change the timestamp value of LD_ID_DYLD to match the one generated by ld64. The dynamic linker (dyld) used to expects different values for timestamp in LD_ID_DYLD and LD_LOAD_DYLD for prebound images. While prebinding is deprecated, we should probably keep it safe and match ld64. Reviewers: kledzik Subscribers: llvm-commits Projects: #lld Differential Revision: http://reviews.llvm.org/D6736 llvm-svn: 224681
2014-12-20 17:22:56 +08:00
# CHECK-BINARY-READ: cmd LC_LOAD_DYLIB
# CHECK-BINARY-READ-NEXT: cmdsize 40
# CHECK-BINARY-READ-NEXT: name libwibble.dylib (offset 24)
# CHECK-BINARY-READ-NEXT: time stamp 2
# CHECK-BINARY-READ-NEXT: current version 5.3.0
# CHECK-BINARY-READ-NEXT: compatibility version 2.0.0