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/dso_handle.yaml

63 lines
1.9 KiB
YAML
Raw Normal View History

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: lld -flavor darwin -arch x86_64 %s %p/Inputs/x86_64/libSystem.yaml -o %t1
[mach-o] Support linker synthesized mach_header symbols. On darwin in final linked images, the __TEXT segment covers that start of the file. That means in memory a process can see the mach_header (and load commands) for every loaded image in a process. There are APIs that take and return the mach_header addresses as a way to specify a particular loaded image. For completeness, any code can get the address of the mach_header of the image it is in by using &__dso_handle. In addition there are mach-o type specific symbols like __mh_execute_header. The linker needs to supply a definition for any of these symbols if used. But the address the symbol it resolves to is not in any section. Instead it is the address of the start of the __TEXT segment. I needed to make a small change to SimpleFileNode to not override resetNextIndex() because the Driver creates a SimpleFileNode to hold the internal/implicit files that the context/writer can create. For some reason SimpleFileNode overrode resetNextIndex() to do nothing instead of reseting the index (which mach-o needs if the internal file is an archive). llvm-svn: 221822
2014-11-13 06:21:56 +08:00
# RUN: llvm-nm -m -n %t1 | FileCheck %s
#
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: lld -flavor darwin -arch x86_64 %s %p/Inputs/x86_64/libSystem.yaml -dead_strip -o %t2
[mach-o] Support linker synthesized mach_header symbols. On darwin in final linked images, the __TEXT segment covers that start of the file. That means in memory a process can see the mach_header (and load commands) for every loaded image in a process. There are APIs that take and return the mach_header addresses as a way to specify a particular loaded image. For completeness, any code can get the address of the mach_header of the image it is in by using &__dso_handle. In addition there are mach-o type specific symbols like __mh_execute_header. The linker needs to supply a definition for any of these symbols if used. But the address the symbol it resolves to is not in any section. Instead it is the address of the start of the __TEXT segment. I needed to make a small change to SimpleFileNode to not override resetNextIndex() because the Driver creates a SimpleFileNode to hold the internal/implicit files that the context/writer can create. For some reason SimpleFileNode overrode resetNextIndex() to do nothing instead of reseting the index (which mach-o needs if the internal file is an archive). llvm-svn: 221822
2014-11-13 06:21:56 +08:00
# RUN: llvm-nm -m -n %t2 | FileCheck %s
#
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: lld -flavor darwin -arch x86_64 %s %p/Inputs/x86_64/libSystem.yaml -dylib -o %t3
[mach-o] Support linker synthesized mach_header symbols. On darwin in final linked images, the __TEXT segment covers that start of the file. That means in memory a process can see the mach_header (and load commands) for every loaded image in a process. There are APIs that take and return the mach_header addresses as a way to specify a particular loaded image. For completeness, any code can get the address of the mach_header of the image it is in by using &__dso_handle. In addition there are mach-o type specific symbols like __mh_execute_header. The linker needs to supply a definition for any of these symbols if used. But the address the symbol it resolves to is not in any section. Instead it is the address of the start of the __TEXT segment. I needed to make a small change to SimpleFileNode to not override resetNextIndex() because the Driver creates a SimpleFileNode to hold the internal/implicit files that the context/writer can create. For some reason SimpleFileNode overrode resetNextIndex() to do nothing instead of reseting the index (which mach-o needs if the internal file is an archive). llvm-svn: 221822
2014-11-13 06:21:56 +08:00
# RUN: llvm-nm -m -n %t3 | FileCheck %s
#
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: lld -flavor darwin -arch x86_64 %s %p/Inputs/x86_64/libSystem.yaml -bundle -o %t4
[mach-o] Support linker synthesized mach_header symbols. On darwin in final linked images, the __TEXT segment covers that start of the file. That means in memory a process can see the mach_header (and load commands) for every loaded image in a process. There are APIs that take and return the mach_header addresses as a way to specify a particular loaded image. For completeness, any code can get the address of the mach_header of the image it is in by using &__dso_handle. In addition there are mach-o type specific symbols like __mh_execute_header. The linker needs to supply a definition for any of these symbols if used. But the address the symbol it resolves to is not in any section. Instead it is the address of the start of the __TEXT segment. I needed to make a small change to SimpleFileNode to not override resetNextIndex() because the Driver creates a SimpleFileNode to hold the internal/implicit files that the context/writer can create. For some reason SimpleFileNode overrode resetNextIndex() to do nothing instead of reseting the index (which mach-o needs if the internal file is an archive). llvm-svn: 221822
2014-11-13 06:21:56 +08:00
# RUN: llvm-nm -m -n %t4 | FileCheck %s
#
# Test that ___dso_handle symbol is available for executables, bundles, and dylibs
#
--- !mach-o
arch: x86_64
file-type: MH_OBJECT
flags: [ MH_SUBSECTIONS_VIA_SYMBOLS ]
sections:
- segment: __TEXT
section: __text
type: S_REGULAR
attributes: [ S_ATTR_PURE_INSTRUCTIONS, S_ATTR_SOME_INSTRUCTIONS ]
address: 0x0000000000000000
content: [ 0x55, 0x48, 0x89, 0xE5, 0x31, 0xC0, 0x5D, 0xC3 ]
- segment: __DATA
section: __data
type: S_REGULAR
attributes: [ ]
Parsed alignment should be a power of 2. 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-24 08:36:37 +08:00
alignment: 8
[mach-o] Support linker synthesized mach_header symbols. On darwin in final linked images, the __TEXT segment covers that start of the file. That means in memory a process can see the mach_header (and load commands) for every loaded image in a process. There are APIs that take and return the mach_header addresses as a way to specify a particular loaded image. For completeness, any code can get the address of the mach_header of the image it is in by using &__dso_handle. In addition there are mach-o type specific symbols like __mh_execute_header. The linker needs to supply a definition for any of these symbols if used. But the address the symbol it resolves to is not in any section. Instead it is the address of the start of the __TEXT segment. I needed to make a small change to SimpleFileNode to not override resetNextIndex() because the Driver creates a SimpleFileNode to hold the internal/implicit files that the context/writer can create. For some reason SimpleFileNode overrode resetNextIndex() to do nothing instead of reseting the index (which mach-o needs if the internal file is an archive). llvm-svn: 221822
2014-11-13 06:21:56 +08:00
address: 0x0000000000000008
content: [ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 ]
relocations:
- offset: 0x00000000
type: X86_64_RELOC_UNSIGNED
length: 3
pc-rel: false
extern: true
symbol: 2
global-symbols:
- name: _d
type: N_SECT
scope: [ N_EXT ]
sect: 2
value: 0x0000000000000008
- name: _main
type: N_SECT
scope: [ N_EXT ]
sect: 1
value: 0x0000000000000000
undefined-symbols:
- name: ___dso_handle
type: N_UNDF
scope: [ N_EXT ]
value: 0x0000000000000000
...
# CHECK_NOT: ___dso_handle
# CHECK: _main