maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/COFF/autoimport-x86.s

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

67 lines
2.6 KiB
ArmAsm
Raw Normal View History

[COFF] Support MinGW automatic dllimport of data Normally, in order to reference exported data symbols from a different DLL, the declarations need to have the dllimport attribute, in order to use the __imp_<var> symbol (which contains an address to the actual variable) instead of the variable itself directly. This isn't an issue in the same way for functions, since any reference to the function without the dllimport attribute will end up as a reference to a thunk which loads the actual target function from the import address table (IAT). GNU ld, in MinGW environments, supports automatically importing data symbols from DLLs, even if the references didn't have the appropriate dllimport attribute. Since the PE/COFF format doesn't support the kind of relocations that this would require, the MinGW's CRT startup code has an custom framework of their own for manually fixing the missing relocations once module is loaded and the target addresses in the IAT are known. For this to work, the linker (originall in GNU ld) creates a list of remaining references needing fixup, which the runtime processes on startup before handing over control to user code. While this feature is rather controversial, it's one of the main features allowing unix style libraries to be used on windows without any extra porting effort. Some sort of automatic fixing of data imports is also necessary for the itanium C++ ABI on windows (as clang implements it right now) for importing vtable pointers in certain cases, see D43184 for some discussion on that. The runtime pseudo relocation handler supports 8/16/32/64 bit addresses, either PC relative references (like IMAGE_REL_*_REL32*) or absolute references (IMAGE_REL_AMD64_ADDR32, IMAGE_REL_AMD64_ADDR32, IMAGE_REL_I386_DIR32). On linking, the relocation is handled as a relocation against the corresponding IAT slot. For the absolute references, a normal base relocation is created, to update the embedded address in case the image is loaded at a different address. The list of runtime pseudo relocations contains the RVA of the imported symbol (the IAT slot), the RVA of the location the relocation should be applied to, and a size of the memory location. When the relocations are fixed at runtime, the difference between the actual IAT slot value and the IAT slot address is added to the reference, doing the right thing for both absolute and relative references. With this patch alone, things work fine for i386 binaries, and mostly for x86_64 binaries, with feature parity with GNU ld. Despite this, there are a few gotchas: - References to data from within code works fine on both x86 architectures, since their relocations consist of plain 32 or 64 bit absolute/relative references. On ARM and AArch64, references to data doesn't consist of a plain 32 or 64 bit embedded address or offset in the code. On ARMNT, it's usually a MOVW+MOVT instruction pair represented by a IMAGE_REL_ARM_MOV32T relocation, each instruction containing 16 bit of the target address), on AArch64, it's usually an ADRP+ADD/LDR/STR instruction pair with an even more complex encoding, storing a PC relative address (with a range of +/- 4 GB). This could theoretically be remedied by extending the runtime pseudo relocation handler with new relocation types, to support these instruction encodings. This isn't an issue for GCC/GNU ld since they don't support windows on ARMNT/AArch64. - For x86_64, if references in code are encoded as 32 bit PC relative offsets, the runtime relocation will fail if the target turns out to be out of range for a 32 bit offset. - Fixing up the relocations at runtime requires making sections writable if necessary, with the VirtualProtect function. In Windows Store/UWP apps, this function is forbidden. These limitations are addressed by a few later patches in lld and llvm. Differential Revision: https://reviews.llvm.org/D50917 llvm-svn: 340726
2018-08-27 16:43:31 +08:00
# REQUIRES: x86
# RUN: echo -e ".global variable\n.global DllMainCRTStartup\n.text\nDllMainCRTStartup:\nret\n.data\nvariable:\n.long 42" > %t-lib.s
# RUN: llvm-mc -triple=x86_64-windows-gnu %t-lib.s -filetype=obj -o %t-lib.obj
# RUN: lld-link -out:%t-lib.dll -dll -entry:DllMainCRTStartup %t-lib.obj -lldmingw -implib:%t-lib.lib
[LLD] [COFF] Add options for disabling auto import and runtime pseudo relocs Allow disabling either the full auto import feature, or just forbidding the cases that require runtime fixups. As long as all auto imported variables are referenced from separate .refptr$<name> sections, we can alias them on top of the IAT entries and don't actually need any runtime fixups via pseudo relocations. LLVM generates references to variables in .refptr stubs, if it isn't known that the variable for sure is defined in the same object module. Runtime pseudo relocs are needed if the addresses of auto imported variables are used in constant initializers though. Fixing up runtime pseudo relocations requires the use of VirtualProtect (which is disallowed in WinStore/UWP apps) or VirtualProtectFromApp. To allow any risk of ambiguity, allow rejecting cases that would require this at the linker stage. This adds support for the --disable-runtime-pseudo-reloc and --disable-auto-import options in the MinGW driver (matching GNU ld.bfd) with corresponding lld private options in the COFF driver. Differential Revision: https://reviews.llvm.org/D78923
2020-04-26 05:49:44 +08:00
# RUN: llvm-mc -triple=x86_64-windows-gnu -defsym listptrs=1 %s -filetype=obj -o %t.obj
[COFF] Omit automatically imported symbols from the symbol table These symbols actually point to the symbol's IAT entry, which obviously is different from the symbol itself (which is imported from a different module and doesn't exist in the current one). Omitting this symbol helps gdb inspect automatically imported symbols, see https://sourceware.org/bugzilla/show_bug.cgi?id=24574 for discussion on the matter. Surprisingly, those extra symbols don't seem to be an issue for gdb when the sources have been built with clang, only with gcc. The actual logic in gdb that this depends on still is unknown, but omitting these symbols from the symbol table is the right thing to do in any case. Differential Revision: https://reviews.llvm.org/D65727 llvm-svn: 367836
2019-08-05 19:57:00 +08:00
# RUN: lld-link -lldmingw -debug:symtab -out:%t.exe -entry:main %t.obj %t-lib.lib -verbose
[COFF] Support MinGW automatic dllimport of data Normally, in order to reference exported data symbols from a different DLL, the declarations need to have the dllimport attribute, in order to use the __imp_<var> symbol (which contains an address to the actual variable) instead of the variable itself directly. This isn't an issue in the same way for functions, since any reference to the function without the dllimport attribute will end up as a reference to a thunk which loads the actual target function from the import address table (IAT). GNU ld, in MinGW environments, supports automatically importing data symbols from DLLs, even if the references didn't have the appropriate dllimport attribute. Since the PE/COFF format doesn't support the kind of relocations that this would require, the MinGW's CRT startup code has an custom framework of their own for manually fixing the missing relocations once module is loaded and the target addresses in the IAT are known. For this to work, the linker (originall in GNU ld) creates a list of remaining references needing fixup, which the runtime processes on startup before handing over control to user code. While this feature is rather controversial, it's one of the main features allowing unix style libraries to be used on windows without any extra porting effort. Some sort of automatic fixing of data imports is also necessary for the itanium C++ ABI on windows (as clang implements it right now) for importing vtable pointers in certain cases, see D43184 for some discussion on that. The runtime pseudo relocation handler supports 8/16/32/64 bit addresses, either PC relative references (like IMAGE_REL_*_REL32*) or absolute references (IMAGE_REL_AMD64_ADDR32, IMAGE_REL_AMD64_ADDR32, IMAGE_REL_I386_DIR32). On linking, the relocation is handled as a relocation against the corresponding IAT slot. For the absolute references, a normal base relocation is created, to update the embedded address in case the image is loaded at a different address. The list of runtime pseudo relocations contains the RVA of the imported symbol (the IAT slot), the RVA of the location the relocation should be applied to, and a size of the memory location. When the relocations are fixed at runtime, the difference between the actual IAT slot value and the IAT slot address is added to the reference, doing the right thing for both absolute and relative references. With this patch alone, things work fine for i386 binaries, and mostly for x86_64 binaries, with feature parity with GNU ld. Despite this, there are a few gotchas: - References to data from within code works fine on both x86 architectures, since their relocations consist of plain 32 or 64 bit absolute/relative references. On ARM and AArch64, references to data doesn't consist of a plain 32 or 64 bit embedded address or offset in the code. On ARMNT, it's usually a MOVW+MOVT instruction pair represented by a IMAGE_REL_ARM_MOV32T relocation, each instruction containing 16 bit of the target address), on AArch64, it's usually an ADRP+ADD/LDR/STR instruction pair with an even more complex encoding, storing a PC relative address (with a range of +/- 4 GB). This could theoretically be remedied by extending the runtime pseudo relocation handler with new relocation types, to support these instruction encodings. This isn't an issue for GCC/GNU ld since they don't support windows on ARMNT/AArch64. - For x86_64, if references in code are encoded as 32 bit PC relative offsets, the runtime relocation will fail if the target turns out to be out of range for a 32 bit offset. - Fixing up the relocations at runtime requires making sections writable if necessary, with the VirtualProtect function. In Windows Store/UWP apps, this function is forbidden. These limitations are addressed by a few later patches in lld and llvm. Differential Revision: https://reviews.llvm.org/D50917 llvm-svn: 340726
2018-08-27 16:43:31 +08:00
[LLD] [COFF] Add options for disabling auto import and runtime pseudo relocs Allow disabling either the full auto import feature, or just forbidding the cases that require runtime fixups. As long as all auto imported variables are referenced from separate .refptr$<name> sections, we can alias them on top of the IAT entries and don't actually need any runtime fixups via pseudo relocations. LLVM generates references to variables in .refptr stubs, if it isn't known that the variable for sure is defined in the same object module. Runtime pseudo relocs are needed if the addresses of auto imported variables are used in constant initializers though. Fixing up runtime pseudo relocations requires the use of VirtualProtect (which is disallowed in WinStore/UWP apps) or VirtualProtectFromApp. To allow any risk of ambiguity, allow rejecting cases that would require this at the linker stage. This adds support for the --disable-runtime-pseudo-reloc and --disable-auto-import options in the MinGW driver (matching GNU ld.bfd) with corresponding lld private options in the COFF driver. Differential Revision: https://reviews.llvm.org/D78923
2020-04-26 05:49:44 +08:00
# RUN: llvm-mc -triple=x86_64-windows-gnu -defsym listptrs=0 %s -filetype=obj -o %t.noptrs.obj
# RUN: not lld-link -lldmingw -runtime-pseudo-reloc:no -debug:symtab -out:%t.exe -entry:main %t.noptrs.obj %t-lib.lib 2>&1 | FileCheck --check-prefix=DISABLED %s
[test] Change llvm-readobj -long-option to --long-option or well-known short 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-05-01 13:49:01 +08:00
# RUN: llvm-readobj --coff-imports %t.exe | FileCheck -check-prefix=IMPORTS %s
[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 -d %t.exe | FileCheck --check-prefix=DISASM %s
# RUN: llvm-objdump -s %t.exe | FileCheck --check-prefix=CONTENTS %s
[COFF] Omit automatically imported symbols from the symbol table These symbols actually point to the symbol's IAT entry, which obviously is different from the symbol itself (which is imported from a different module and doesn't exist in the current one). Omitting this symbol helps gdb inspect automatically imported symbols, see https://sourceware.org/bugzilla/show_bug.cgi?id=24574 for discussion on the matter. Surprisingly, those extra symbols don't seem to be an issue for gdb when the sources have been built with clang, only with gcc. The actual logic in gdb that this depends on still is unknown, but omitting these symbols from the symbol table is the right thing to do in any case. Differential Revision: https://reviews.llvm.org/D65727 llvm-svn: 367836
2019-08-05 19:57:00 +08:00
# RUN: llvm-nm %t.exe | FileCheck -check-prefix=SYMBOLS %s
[COFF] Support MinGW automatic dllimport of data Normally, in order to reference exported data symbols from a different DLL, the declarations need to have the dllimport attribute, in order to use the __imp_<var> symbol (which contains an address to the actual variable) instead of the variable itself directly. This isn't an issue in the same way for functions, since any reference to the function without the dllimport attribute will end up as a reference to a thunk which loads the actual target function from the import address table (IAT). GNU ld, in MinGW environments, supports automatically importing data symbols from DLLs, even if the references didn't have the appropriate dllimport attribute. Since the PE/COFF format doesn't support the kind of relocations that this would require, the MinGW's CRT startup code has an custom framework of their own for manually fixing the missing relocations once module is loaded and the target addresses in the IAT are known. For this to work, the linker (originall in GNU ld) creates a list of remaining references needing fixup, which the runtime processes on startup before handing over control to user code. While this feature is rather controversial, it's one of the main features allowing unix style libraries to be used on windows without any extra porting effort. Some sort of automatic fixing of data imports is also necessary for the itanium C++ ABI on windows (as clang implements it right now) for importing vtable pointers in certain cases, see D43184 for some discussion on that. The runtime pseudo relocation handler supports 8/16/32/64 bit addresses, either PC relative references (like IMAGE_REL_*_REL32*) or absolute references (IMAGE_REL_AMD64_ADDR32, IMAGE_REL_AMD64_ADDR32, IMAGE_REL_I386_DIR32). On linking, the relocation is handled as a relocation against the corresponding IAT slot. For the absolute references, a normal base relocation is created, to update the embedded address in case the image is loaded at a different address. The list of runtime pseudo relocations contains the RVA of the imported symbol (the IAT slot), the RVA of the location the relocation should be applied to, and a size of the memory location. When the relocations are fixed at runtime, the difference between the actual IAT slot value and the IAT slot address is added to the reference, doing the right thing for both absolute and relative references. With this patch alone, things work fine for i386 binaries, and mostly for x86_64 binaries, with feature parity with GNU ld. Despite this, there are a few gotchas: - References to data from within code works fine on both x86 architectures, since their relocations consist of plain 32 or 64 bit absolute/relative references. On ARM and AArch64, references to data doesn't consist of a plain 32 or 64 bit embedded address or offset in the code. On ARMNT, it's usually a MOVW+MOVT instruction pair represented by a IMAGE_REL_ARM_MOV32T relocation, each instruction containing 16 bit of the target address), on AArch64, it's usually an ADRP+ADD/LDR/STR instruction pair with an even more complex encoding, storing a PC relative address (with a range of +/- 4 GB). This could theoretically be remedied by extending the runtime pseudo relocation handler with new relocation types, to support these instruction encodings. This isn't an issue for GCC/GNU ld since they don't support windows on ARMNT/AArch64. - For x86_64, if references in code are encoded as 32 bit PC relative offsets, the runtime relocation will fail if the target turns out to be out of range for a 32 bit offset. - Fixing up the relocations at runtime requires making sections writable if necessary, with the VirtualProtect function. In Windows Store/UWP apps, this function is forbidden. These limitations are addressed by a few later patches in lld and llvm. Differential Revision: https://reviews.llvm.org/D50917 llvm-svn: 340726
2018-08-27 16:43:31 +08:00
# IMPORTS: Import {
# IMPORTS-NEXT: Name: autoimport-x86.s.tmp-lib.dll
[COFF] Provide __CTOR_LIST__ and __DTOR_LIST__ symbols for MinGW MinGW uses these kind of list terminator symbols for traversing the constructor/destructor lists. These list terminators are actual pointers entries in the lists, with the values 0 and (uintptr_t)-1 (instead of just symbols pointing to the start/end of the list). (This mechanism exists in both the mingw-w64 crt startup code and in libgcc; normally the mingw-w64 one is used, but a DLL build of libgcc uses the libgcc one. Therefore it's not trivial to change the mechanism without lots of cross-project synchronization and potentially invalidating some combinations of old/new versions of them.) When mingw-w64 has been used with lld so far, the CRT startup object files have so far provided these symbols, ending up with different, incompatible builds of the CRT startup object files depending on whether binutils or lld are going to be used. In order to avoid the need of different configuration of the CRT startup object files depending on what linker to be used, provide these symbols in lld instead. (Mingw-w64 checks at build time whether the linker provides these symbols or not.) This unifies this particular detail between the two linkers. This does disallow the use of the very latest lld with older versions of mingw-w64 (the configure check for the list was added recently; earlier it simply checked whether the CRT was built with gcc or clang), and requires rebuilding the mingw-w64 CRT. But the number of users of lld+mingw still is low enough that such a change should be tolerable, and unifies this aspect of the toolchains, easing interoperability between the toolchains for the future. The actual test for this feature is added in ctors_dtors_priority.s, but a number of other tests that checked absolute output addresses are updated. Differential Revision: https://reviews.llvm.org/D52053 llvm-svn: 342294
2018-09-15 06:26:59 +08:00
# IMPORTS-NEXT: ImportLookupTableRVA: 0x2070
# IMPORTS-NEXT: ImportAddressTableRVA: 0x2080
[COFF] Support MinGW automatic dllimport of data Normally, in order to reference exported data symbols from a different DLL, the declarations need to have the dllimport attribute, in order to use the __imp_<var> symbol (which contains an address to the actual variable) instead of the variable itself directly. This isn't an issue in the same way for functions, since any reference to the function without the dllimport attribute will end up as a reference to a thunk which loads the actual target function from the import address table (IAT). GNU ld, in MinGW environments, supports automatically importing data symbols from DLLs, even if the references didn't have the appropriate dllimport attribute. Since the PE/COFF format doesn't support the kind of relocations that this would require, the MinGW's CRT startup code has an custom framework of their own for manually fixing the missing relocations once module is loaded and the target addresses in the IAT are known. For this to work, the linker (originall in GNU ld) creates a list of remaining references needing fixup, which the runtime processes on startup before handing over control to user code. While this feature is rather controversial, it's one of the main features allowing unix style libraries to be used on windows without any extra porting effort. Some sort of automatic fixing of data imports is also necessary for the itanium C++ ABI on windows (as clang implements it right now) for importing vtable pointers in certain cases, see D43184 for some discussion on that. The runtime pseudo relocation handler supports 8/16/32/64 bit addresses, either PC relative references (like IMAGE_REL_*_REL32*) or absolute references (IMAGE_REL_AMD64_ADDR32, IMAGE_REL_AMD64_ADDR32, IMAGE_REL_I386_DIR32). On linking, the relocation is handled as a relocation against the corresponding IAT slot. For the absolute references, a normal base relocation is created, to update the embedded address in case the image is loaded at a different address. The list of runtime pseudo relocations contains the RVA of the imported symbol (the IAT slot), the RVA of the location the relocation should be applied to, and a size of the memory location. When the relocations are fixed at runtime, the difference between the actual IAT slot value and the IAT slot address is added to the reference, doing the right thing for both absolute and relative references. With this patch alone, things work fine for i386 binaries, and mostly for x86_64 binaries, with feature parity with GNU ld. Despite this, there are a few gotchas: - References to data from within code works fine on both x86 architectures, since their relocations consist of plain 32 or 64 bit absolute/relative references. On ARM and AArch64, references to data doesn't consist of a plain 32 or 64 bit embedded address or offset in the code. On ARMNT, it's usually a MOVW+MOVT instruction pair represented by a IMAGE_REL_ARM_MOV32T relocation, each instruction containing 16 bit of the target address), on AArch64, it's usually an ADRP+ADD/LDR/STR instruction pair with an even more complex encoding, storing a PC relative address (with a range of +/- 4 GB). This could theoretically be remedied by extending the runtime pseudo relocation handler with new relocation types, to support these instruction encodings. This isn't an issue for GCC/GNU ld since they don't support windows on ARMNT/AArch64. - For x86_64, if references in code are encoded as 32 bit PC relative offsets, the runtime relocation will fail if the target turns out to be out of range for a 32 bit offset. - Fixing up the relocations at runtime requires making sections writable if necessary, with the VirtualProtect function. In Windows Store/UWP apps, this function is forbidden. These limitations are addressed by a few later patches in lld and llvm. Differential Revision: https://reviews.llvm.org/D50917 llvm-svn: 340726
2018-08-27 16:43:31 +08:00
# IMPORTS-NEXT: Symbol: variable (0)
# IMPORTS-NEXT: }
# DISASM: Disassembly of section .text:
[llvm-objdump] Print newlines before and after "Disassembly of section ...:" This improves readability and the behavior is consistent with GNU objdump. The new test test/tools/llvm-objdump/X86/disassemble-section-name.s checks we print newlines before and after "Disassembly of section ...:" Differential Revision: https://reviews.llvm.org/D61127 llvm-svn: 359668
2019-05-01 18:40:48 +08:00
# DISASM-EMPTY:
[llvm-objdump] -d: print `00000000 <foo>:` instead of `00000000 foo:` The new behavior matches GNU objdump. A pair of angle brackets makes tests slightly easier. `.foo:` is not unique and thus cannot be used in a `CHECK-LABEL:` directive. Without `-LABEL`, the CHECK line can match the `Disassembly of section` line and causes the next `CHECK-NEXT:` to fail. ``` Disassembly of section .foo: 0000000000001634 .foo: ``` Bdragon: <> has metalinguistic connotation. it just "feels right" Reviewed By: rupprecht Differential Revision: https://reviews.llvm.org/D75713
2020-03-06 06:18:38 +08:00
# DISASM: <main>:
[COFF] Provide __CTOR_LIST__ and __DTOR_LIST__ symbols for MinGW MinGW uses these kind of list terminator symbols for traversing the constructor/destructor lists. These list terminators are actual pointers entries in the lists, with the values 0 and (uintptr_t)-1 (instead of just symbols pointing to the start/end of the list). (This mechanism exists in both the mingw-w64 crt startup code and in libgcc; normally the mingw-w64 one is used, but a DLL build of libgcc uses the libgcc one. Therefore it's not trivial to change the mechanism without lots of cross-project synchronization and potentially invalidating some combinations of old/new versions of them.) When mingw-w64 has been used with lld so far, the CRT startup object files have so far provided these symbols, ending up with different, incompatible builds of the CRT startup object files depending on whether binutils or lld are going to be used. In order to avoid the need of different configuration of the CRT startup object files depending on what linker to be used, provide these symbols in lld instead. (Mingw-w64 checks at build time whether the linker provides these symbols or not.) This unifies this particular detail between the two linkers. This does disallow the use of the very latest lld with older versions of mingw-w64 (the configure check for the list was added recently; earlier it simply checked whether the CRT was built with gcc or clang), and requires rebuilding the mingw-w64 CRT. But the number of users of lld+mingw still is low enough that such a change should be tolerable, and unifies this aspect of the toolchains, easing interoperability between the toolchains for the future. The actual test for this feature is added in ctors_dtors_priority.s, but a number of other tests that checked absolute output addresses are updated. Differential Revision: https://reviews.llvm.org/D52053 llvm-svn: 342294
2018-09-15 06:26:59 +08:00
# Relative offset at 0x1002 pointing at the IAT at 0x2080.
# DISASM: 140001000: 8b 05 7a 10 00 00 movl 4218(%rip), %eax
[COFF] Support MinGW automatic dllimport of data Normally, in order to reference exported data symbols from a different DLL, the declarations need to have the dllimport attribute, in order to use the __imp_<var> symbol (which contains an address to the actual variable) instead of the variable itself directly. This isn't an issue in the same way for functions, since any reference to the function without the dllimport attribute will end up as a reference to a thunk which loads the actual target function from the import address table (IAT). GNU ld, in MinGW environments, supports automatically importing data symbols from DLLs, even if the references didn't have the appropriate dllimport attribute. Since the PE/COFF format doesn't support the kind of relocations that this would require, the MinGW's CRT startup code has an custom framework of their own for manually fixing the missing relocations once module is loaded and the target addresses in the IAT are known. For this to work, the linker (originall in GNU ld) creates a list of remaining references needing fixup, which the runtime processes on startup before handing over control to user code. While this feature is rather controversial, it's one of the main features allowing unix style libraries to be used on windows without any extra porting effort. Some sort of automatic fixing of data imports is also necessary for the itanium C++ ABI on windows (as clang implements it right now) for importing vtable pointers in certain cases, see D43184 for some discussion on that. The runtime pseudo relocation handler supports 8/16/32/64 bit addresses, either PC relative references (like IMAGE_REL_*_REL32*) or absolute references (IMAGE_REL_AMD64_ADDR32, IMAGE_REL_AMD64_ADDR32, IMAGE_REL_I386_DIR32). On linking, the relocation is handled as a relocation against the corresponding IAT slot. For the absolute references, a normal base relocation is created, to update the embedded address in case the image is loaded at a different address. The list of runtime pseudo relocations contains the RVA of the imported symbol (the IAT slot), the RVA of the location the relocation should be applied to, and a size of the memory location. When the relocations are fixed at runtime, the difference between the actual IAT slot value and the IAT slot address is added to the reference, doing the right thing for both absolute and relative references. With this patch alone, things work fine for i386 binaries, and mostly for x86_64 binaries, with feature parity with GNU ld. Despite this, there are a few gotchas: - References to data from within code works fine on both x86 architectures, since their relocations consist of plain 32 or 64 bit absolute/relative references. On ARM and AArch64, references to data doesn't consist of a plain 32 or 64 bit embedded address or offset in the code. On ARMNT, it's usually a MOVW+MOVT instruction pair represented by a IMAGE_REL_ARM_MOV32T relocation, each instruction containing 16 bit of the target address), on AArch64, it's usually an ADRP+ADD/LDR/STR instruction pair with an even more complex encoding, storing a PC relative address (with a range of +/- 4 GB). This could theoretically be remedied by extending the runtime pseudo relocation handler with new relocation types, to support these instruction encodings. This isn't an issue for GCC/GNU ld since they don't support windows on ARMNT/AArch64. - For x86_64, if references in code are encoded as 32 bit PC relative offsets, the runtime relocation will fail if the target turns out to be out of range for a 32 bit offset. - Fixing up the relocations at runtime requires making sections writable if necessary, with the VirtualProtect function. In Windows Store/UWP apps, this function is forbidden. These limitations are addressed by a few later patches in lld and llvm. Differential Revision: https://reviews.llvm.org/D50917 llvm-svn: 340726
2018-08-27 16:43:31 +08:00
# DISASM: 140001006: c3 retq
# Runtime pseudo reloc list header consisting of 0x0, 0x0, 0x1.
[COFF] Provide __CTOR_LIST__ and __DTOR_LIST__ symbols for MinGW MinGW uses these kind of list terminator symbols for traversing the constructor/destructor lists. These list terminators are actual pointers entries in the lists, with the values 0 and (uintptr_t)-1 (instead of just symbols pointing to the start/end of the list). (This mechanism exists in both the mingw-w64 crt startup code and in libgcc; normally the mingw-w64 one is used, but a DLL build of libgcc uses the libgcc one. Therefore it's not trivial to change the mechanism without lots of cross-project synchronization and potentially invalidating some combinations of old/new versions of them.) When mingw-w64 has been used with lld so far, the CRT startup object files have so far provided these symbols, ending up with different, incompatible builds of the CRT startup object files depending on whether binutils or lld are going to be used. In order to avoid the need of different configuration of the CRT startup object files depending on what linker to be used, provide these symbols in lld instead. (Mingw-w64 checks at build time whether the linker provides these symbols or not.) This unifies this particular detail between the two linkers. This does disallow the use of the very latest lld with older versions of mingw-w64 (the configure check for the list was added recently; earlier it simply checked whether the CRT was built with gcc or clang), and requires rebuilding the mingw-w64 CRT. But the number of users of lld+mingw still is low enough that such a change should be tolerable, and unifies this aspect of the toolchains, easing interoperability between the toolchains for the future. The actual test for this feature is added in ctors_dtors_priority.s, but a number of other tests that checked absolute output addresses are updated. Differential Revision: https://reviews.llvm.org/D52053 llvm-svn: 342294
2018-09-15 06:26:59 +08:00
# First runtime pseudo reloc, with import from 0x2080,
[COFF] Support MinGW automatic dllimport of data Normally, in order to reference exported data symbols from a different DLL, the declarations need to have the dllimport attribute, in order to use the __imp_<var> symbol (which contains an address to the actual variable) instead of the variable itself directly. This isn't an issue in the same way for functions, since any reference to the function without the dllimport attribute will end up as a reference to a thunk which loads the actual target function from the import address table (IAT). GNU ld, in MinGW environments, supports automatically importing data symbols from DLLs, even if the references didn't have the appropriate dllimport attribute. Since the PE/COFF format doesn't support the kind of relocations that this would require, the MinGW's CRT startup code has an custom framework of their own for manually fixing the missing relocations once module is loaded and the target addresses in the IAT are known. For this to work, the linker (originall in GNU ld) creates a list of remaining references needing fixup, which the runtime processes on startup before handing over control to user code. While this feature is rather controversial, it's one of the main features allowing unix style libraries to be used on windows without any extra porting effort. Some sort of automatic fixing of data imports is also necessary for the itanium C++ ABI on windows (as clang implements it right now) for importing vtable pointers in certain cases, see D43184 for some discussion on that. The runtime pseudo relocation handler supports 8/16/32/64 bit addresses, either PC relative references (like IMAGE_REL_*_REL32*) or absolute references (IMAGE_REL_AMD64_ADDR32, IMAGE_REL_AMD64_ADDR32, IMAGE_REL_I386_DIR32). On linking, the relocation is handled as a relocation against the corresponding IAT slot. For the absolute references, a normal base relocation is created, to update the embedded address in case the image is loaded at a different address. The list of runtime pseudo relocations contains the RVA of the imported symbol (the IAT slot), the RVA of the location the relocation should be applied to, and a size of the memory location. When the relocations are fixed at runtime, the difference between the actual IAT slot value and the IAT slot address is added to the reference, doing the right thing for both absolute and relative references. With this patch alone, things work fine for i386 binaries, and mostly for x86_64 binaries, with feature parity with GNU ld. Despite this, there are a few gotchas: - References to data from within code works fine on both x86 architectures, since their relocations consist of plain 32 or 64 bit absolute/relative references. On ARM and AArch64, references to data doesn't consist of a plain 32 or 64 bit embedded address or offset in the code. On ARMNT, it's usually a MOVW+MOVT instruction pair represented by a IMAGE_REL_ARM_MOV32T relocation, each instruction containing 16 bit of the target address), on AArch64, it's usually an ADRP+ADD/LDR/STR instruction pair with an even more complex encoding, storing a PC relative address (with a range of +/- 4 GB). This could theoretically be remedied by extending the runtime pseudo relocation handler with new relocation types, to support these instruction encodings. This isn't an issue for GCC/GNU ld since they don't support windows on ARMNT/AArch64. - For x86_64, if references in code are encoded as 32 bit PC relative offsets, the runtime relocation will fail if the target turns out to be out of range for a 32 bit offset. - Fixing up the relocations at runtime requires making sections writable if necessary, with the VirtualProtect function. In Windows Store/UWP apps, this function is forbidden. These limitations are addressed by a few later patches in lld and llvm. Differential Revision: https://reviews.llvm.org/D50917 llvm-svn: 340726
2018-08-27 16:43:31 +08:00
# applied at 0x1002, with a size of 32 bits.
[COFF] Provide __CTOR_LIST__ and __DTOR_LIST__ symbols for MinGW MinGW uses these kind of list terminator symbols for traversing the constructor/destructor lists. These list terminators are actual pointers entries in the lists, with the values 0 and (uintptr_t)-1 (instead of just symbols pointing to the start/end of the list). (This mechanism exists in both the mingw-w64 crt startup code and in libgcc; normally the mingw-w64 one is used, but a DLL build of libgcc uses the libgcc one. Therefore it's not trivial to change the mechanism without lots of cross-project synchronization and potentially invalidating some combinations of old/new versions of them.) When mingw-w64 has been used with lld so far, the CRT startup object files have so far provided these symbols, ending up with different, incompatible builds of the CRT startup object files depending on whether binutils or lld are going to be used. In order to avoid the need of different configuration of the CRT startup object files depending on what linker to be used, provide these symbols in lld instead. (Mingw-w64 checks at build time whether the linker provides these symbols or not.) This unifies this particular detail between the two linkers. This does disallow the use of the very latest lld with older versions of mingw-w64 (the configure check for the list was added recently; earlier it simply checked whether the CRT was built with gcc or clang), and requires rebuilding the mingw-w64 CRT. But the number of users of lld+mingw still is low enough that such a change should be tolerable, and unifies this aspect of the toolchains, easing interoperability between the toolchains for the future. The actual test for this feature is added in ctors_dtors_priority.s, but a number of other tests that checked absolute output addresses are updated. Differential Revision: https://reviews.llvm.org/D52053 llvm-svn: 342294
2018-09-15 06:26:59 +08:00
# Second runtime pseudo reloc, with import from 0x2080,
[COFF] Support MinGW automatic dllimport of data Normally, in order to reference exported data symbols from a different DLL, the declarations need to have the dllimport attribute, in order to use the __imp_<var> symbol (which contains an address to the actual variable) instead of the variable itself directly. This isn't an issue in the same way for functions, since any reference to the function without the dllimport attribute will end up as a reference to a thunk which loads the actual target function from the import address table (IAT). GNU ld, in MinGW environments, supports automatically importing data symbols from DLLs, even if the references didn't have the appropriate dllimport attribute. Since the PE/COFF format doesn't support the kind of relocations that this would require, the MinGW's CRT startup code has an custom framework of their own for manually fixing the missing relocations once module is loaded and the target addresses in the IAT are known. For this to work, the linker (originall in GNU ld) creates a list of remaining references needing fixup, which the runtime processes on startup before handing over control to user code. While this feature is rather controversial, it's one of the main features allowing unix style libraries to be used on windows without any extra porting effort. Some sort of automatic fixing of data imports is also necessary for the itanium C++ ABI on windows (as clang implements it right now) for importing vtable pointers in certain cases, see D43184 for some discussion on that. The runtime pseudo relocation handler supports 8/16/32/64 bit addresses, either PC relative references (like IMAGE_REL_*_REL32*) or absolute references (IMAGE_REL_AMD64_ADDR32, IMAGE_REL_AMD64_ADDR32, IMAGE_REL_I386_DIR32). On linking, the relocation is handled as a relocation against the corresponding IAT slot. For the absolute references, a normal base relocation is created, to update the embedded address in case the image is loaded at a different address. The list of runtime pseudo relocations contains the RVA of the imported symbol (the IAT slot), the RVA of the location the relocation should be applied to, and a size of the memory location. When the relocations are fixed at runtime, the difference between the actual IAT slot value and the IAT slot address is added to the reference, doing the right thing for both absolute and relative references. With this patch alone, things work fine for i386 binaries, and mostly for x86_64 binaries, with feature parity with GNU ld. Despite this, there are a few gotchas: - References to data from within code works fine on both x86 architectures, since their relocations consist of plain 32 or 64 bit absolute/relative references. On ARM and AArch64, references to data doesn't consist of a plain 32 or 64 bit embedded address or offset in the code. On ARMNT, it's usually a MOVW+MOVT instruction pair represented by a IMAGE_REL_ARM_MOV32T relocation, each instruction containing 16 bit of the target address), on AArch64, it's usually an ADRP+ADD/LDR/STR instruction pair with an even more complex encoding, storing a PC relative address (with a range of +/- 4 GB). This could theoretically be remedied by extending the runtime pseudo relocation handler with new relocation types, to support these instruction encodings. This isn't an issue for GCC/GNU ld since they don't support windows on ARMNT/AArch64. - For x86_64, if references in code are encoded as 32 bit PC relative offsets, the runtime relocation will fail if the target turns out to be out of range for a 32 bit offset. - Fixing up the relocations at runtime requires making sections writable if necessary, with the VirtualProtect function. In Windows Store/UWP apps, this function is forbidden. These limitations are addressed by a few later patches in lld and llvm. Differential Revision: https://reviews.llvm.org/D50917 llvm-svn: 340726
2018-08-27 16:43:31 +08:00
# applied at 0x3000, with a size of 64 bits.
# CONTENTS: Contents of section .rdata:
[COFF] Provide __CTOR_LIST__ and __DTOR_LIST__ symbols for MinGW MinGW uses these kind of list terminator symbols for traversing the constructor/destructor lists. These list terminators are actual pointers entries in the lists, with the values 0 and (uintptr_t)-1 (instead of just symbols pointing to the start/end of the list). (This mechanism exists in both the mingw-w64 crt startup code and in libgcc; normally the mingw-w64 one is used, but a DLL build of libgcc uses the libgcc one. Therefore it's not trivial to change the mechanism without lots of cross-project synchronization and potentially invalidating some combinations of old/new versions of them.) When mingw-w64 has been used with lld so far, the CRT startup object files have so far provided these symbols, ending up with different, incompatible builds of the CRT startup object files depending on whether binutils or lld are going to be used. In order to avoid the need of different configuration of the CRT startup object files depending on what linker to be used, provide these symbols in lld instead. (Mingw-w64 checks at build time whether the linker provides these symbols or not.) This unifies this particular detail between the two linkers. This does disallow the use of the very latest lld with older versions of mingw-w64 (the configure check for the list was added recently; earlier it simply checked whether the CRT was built with gcc or clang), and requires rebuilding the mingw-w64 CRT. But the number of users of lld+mingw still is low enough that such a change should be tolerable, and unifies this aspect of the toolchains, easing interoperability between the toolchains for the future. The actual test for this feature is added in ctors_dtors_priority.s, but a number of other tests that checked absolute output addresses are updated. Differential Revision: https://reviews.llvm.org/D52053 llvm-svn: 342294
2018-09-15 06:26:59 +08:00
# CONTENTS: 140002000 00000000 00000000 01000000 80200000
# CONTENTS: 140002010 02100000 20000000 80200000 00300000
[COFF] Support MinGW automatic dllimport of data Normally, in order to reference exported data symbols from a different DLL, the declarations need to have the dllimport attribute, in order to use the __imp_<var> symbol (which contains an address to the actual variable) instead of the variable itself directly. This isn't an issue in the same way for functions, since any reference to the function without the dllimport attribute will end up as a reference to a thunk which loads the actual target function from the import address table (IAT). GNU ld, in MinGW environments, supports automatically importing data symbols from DLLs, even if the references didn't have the appropriate dllimport attribute. Since the PE/COFF format doesn't support the kind of relocations that this would require, the MinGW's CRT startup code has an custom framework of their own for manually fixing the missing relocations once module is loaded and the target addresses in the IAT are known. For this to work, the linker (originall in GNU ld) creates a list of remaining references needing fixup, which the runtime processes on startup before handing over control to user code. While this feature is rather controversial, it's one of the main features allowing unix style libraries to be used on windows without any extra porting effort. Some sort of automatic fixing of data imports is also necessary for the itanium C++ ABI on windows (as clang implements it right now) for importing vtable pointers in certain cases, see D43184 for some discussion on that. The runtime pseudo relocation handler supports 8/16/32/64 bit addresses, either PC relative references (like IMAGE_REL_*_REL32*) or absolute references (IMAGE_REL_AMD64_ADDR32, IMAGE_REL_AMD64_ADDR32, IMAGE_REL_I386_DIR32). On linking, the relocation is handled as a relocation against the corresponding IAT slot. For the absolute references, a normal base relocation is created, to update the embedded address in case the image is loaded at a different address. The list of runtime pseudo relocations contains the RVA of the imported symbol (the IAT slot), the RVA of the location the relocation should be applied to, and a size of the memory location. When the relocations are fixed at runtime, the difference between the actual IAT slot value and the IAT slot address is added to the reference, doing the right thing for both absolute and relative references. With this patch alone, things work fine for i386 binaries, and mostly for x86_64 binaries, with feature parity with GNU ld. Despite this, there are a few gotchas: - References to data from within code works fine on both x86 architectures, since their relocations consist of plain 32 or 64 bit absolute/relative references. On ARM and AArch64, references to data doesn't consist of a plain 32 or 64 bit embedded address or offset in the code. On ARMNT, it's usually a MOVW+MOVT instruction pair represented by a IMAGE_REL_ARM_MOV32T relocation, each instruction containing 16 bit of the target address), on AArch64, it's usually an ADRP+ADD/LDR/STR instruction pair with an even more complex encoding, storing a PC relative address (with a range of +/- 4 GB). This could theoretically be remedied by extending the runtime pseudo relocation handler with new relocation types, to support these instruction encodings. This isn't an issue for GCC/GNU ld since they don't support windows on ARMNT/AArch64. - For x86_64, if references in code are encoded as 32 bit PC relative offsets, the runtime relocation will fail if the target turns out to be out of range for a 32 bit offset. - Fixing up the relocations at runtime requires making sections writable if necessary, with the VirtualProtect function. In Windows Store/UWP apps, this function is forbidden. These limitations are addressed by a few later patches in lld and llvm. Differential Revision: https://reviews.llvm.org/D50917 llvm-svn: 340726
2018-08-27 16:43:31 +08:00
# CONTENTS: 140002020 40000000
[COFF] Provide __CTOR_LIST__ and __DTOR_LIST__ symbols for MinGW MinGW uses these kind of list terminator symbols for traversing the constructor/destructor lists. These list terminators are actual pointers entries in the lists, with the values 0 and (uintptr_t)-1 (instead of just symbols pointing to the start/end of the list). (This mechanism exists in both the mingw-w64 crt startup code and in libgcc; normally the mingw-w64 one is used, but a DLL build of libgcc uses the libgcc one. Therefore it's not trivial to change the mechanism without lots of cross-project synchronization and potentially invalidating some combinations of old/new versions of them.) When mingw-w64 has been used with lld so far, the CRT startup object files have so far provided these symbols, ending up with different, incompatible builds of the CRT startup object files depending on whether binutils or lld are going to be used. In order to avoid the need of different configuration of the CRT startup object files depending on what linker to be used, provide these symbols in lld instead. (Mingw-w64 checks at build time whether the linker provides these symbols or not.) This unifies this particular detail between the two linkers. This does disallow the use of the very latest lld with older versions of mingw-w64 (the configure check for the list was added recently; earlier it simply checked whether the CRT was built with gcc or clang), and requires rebuilding the mingw-w64 CRT. But the number of users of lld+mingw still is low enough that such a change should be tolerable, and unifies this aspect of the toolchains, easing interoperability between the toolchains for the future. The actual test for this feature is added in ctors_dtors_priority.s, but a number of other tests that checked absolute output addresses are updated. Differential Revision: https://reviews.llvm.org/D52053 llvm-svn: 342294
2018-09-15 06:26:59 +08:00
# ptr: pointing at the IAT RVA at 0x2080
[COFF] Support MinGW automatic dllimport of data Normally, in order to reference exported data symbols from a different DLL, the declarations need to have the dllimport attribute, in order to use the __imp_<var> symbol (which contains an address to the actual variable) instead of the variable itself directly. This isn't an issue in the same way for functions, since any reference to the function without the dllimport attribute will end up as a reference to a thunk which loads the actual target function from the import address table (IAT). GNU ld, in MinGW environments, supports automatically importing data symbols from DLLs, even if the references didn't have the appropriate dllimport attribute. Since the PE/COFF format doesn't support the kind of relocations that this would require, the MinGW's CRT startup code has an custom framework of their own for manually fixing the missing relocations once module is loaded and the target addresses in the IAT are known. For this to work, the linker (originall in GNU ld) creates a list of remaining references needing fixup, which the runtime processes on startup before handing over control to user code. While this feature is rather controversial, it's one of the main features allowing unix style libraries to be used on windows without any extra porting effort. Some sort of automatic fixing of data imports is also necessary for the itanium C++ ABI on windows (as clang implements it right now) for importing vtable pointers in certain cases, see D43184 for some discussion on that. The runtime pseudo relocation handler supports 8/16/32/64 bit addresses, either PC relative references (like IMAGE_REL_*_REL32*) or absolute references (IMAGE_REL_AMD64_ADDR32, IMAGE_REL_AMD64_ADDR32, IMAGE_REL_I386_DIR32). On linking, the relocation is handled as a relocation against the corresponding IAT slot. For the absolute references, a normal base relocation is created, to update the embedded address in case the image is loaded at a different address. The list of runtime pseudo relocations contains the RVA of the imported symbol (the IAT slot), the RVA of the location the relocation should be applied to, and a size of the memory location. When the relocations are fixed at runtime, the difference between the actual IAT slot value and the IAT slot address is added to the reference, doing the right thing for both absolute and relative references. With this patch alone, things work fine for i386 binaries, and mostly for x86_64 binaries, with feature parity with GNU ld. Despite this, there are a few gotchas: - References to data from within code works fine on both x86 architectures, since their relocations consist of plain 32 or 64 bit absolute/relative references. On ARM and AArch64, references to data doesn't consist of a plain 32 or 64 bit embedded address or offset in the code. On ARMNT, it's usually a MOVW+MOVT instruction pair represented by a IMAGE_REL_ARM_MOV32T relocation, each instruction containing 16 bit of the target address), on AArch64, it's usually an ADRP+ADD/LDR/STR instruction pair with an even more complex encoding, storing a PC relative address (with a range of +/- 4 GB). This could theoretically be remedied by extending the runtime pseudo relocation handler with new relocation types, to support these instruction encodings. This isn't an issue for GCC/GNU ld since they don't support windows on ARMNT/AArch64. - For x86_64, if references in code are encoded as 32 bit PC relative offsets, the runtime relocation will fail if the target turns out to be out of range for a 32 bit offset. - Fixing up the relocations at runtime requires making sections writable if necessary, with the VirtualProtect function. In Windows Store/UWP apps, this function is forbidden. These limitations are addressed by a few later patches in lld and llvm. Differential Revision: https://reviews.llvm.org/D50917 llvm-svn: 340726
2018-08-27 16:43:31 +08:00
# relocs: pointing at the runtime pseudo reloc list at
# 0x2000 - 0x2024.
# CONTENTS: Contents of section .data:
[COFF] Provide __CTOR_LIST__ and __DTOR_LIST__ symbols for MinGW MinGW uses these kind of list terminator symbols for traversing the constructor/destructor lists. These list terminators are actual pointers entries in the lists, with the values 0 and (uintptr_t)-1 (instead of just symbols pointing to the start/end of the list). (This mechanism exists in both the mingw-w64 crt startup code and in libgcc; normally the mingw-w64 one is used, but a DLL build of libgcc uses the libgcc one. Therefore it's not trivial to change the mechanism without lots of cross-project synchronization and potentially invalidating some combinations of old/new versions of them.) When mingw-w64 has been used with lld so far, the CRT startup object files have so far provided these symbols, ending up with different, incompatible builds of the CRT startup object files depending on whether binutils or lld are going to be used. In order to avoid the need of different configuration of the CRT startup object files depending on what linker to be used, provide these symbols in lld instead. (Mingw-w64 checks at build time whether the linker provides these symbols or not.) This unifies this particular detail between the two linkers. This does disallow the use of the very latest lld with older versions of mingw-w64 (the configure check for the list was added recently; earlier it simply checked whether the CRT was built with gcc or clang), and requires rebuilding the mingw-w64 CRT. But the number of users of lld+mingw still is low enough that such a change should be tolerable, and unifies this aspect of the toolchains, easing interoperability between the toolchains for the future. The actual test for this feature is added in ctors_dtors_priority.s, but a number of other tests that checked absolute output addresses are updated. Differential Revision: https://reviews.llvm.org/D52053 llvm-svn: 342294
2018-09-15 06:26:59 +08:00
# CONTENTS: 140003000 80200040 01000000 00200040 01000000
[COFF] Support MinGW automatic dllimport of data Normally, in order to reference exported data symbols from a different DLL, the declarations need to have the dllimport attribute, in order to use the __imp_<var> symbol (which contains an address to the actual variable) instead of the variable itself directly. This isn't an issue in the same way for functions, since any reference to the function without the dllimport attribute will end up as a reference to a thunk which loads the actual target function from the import address table (IAT). GNU ld, in MinGW environments, supports automatically importing data symbols from DLLs, even if the references didn't have the appropriate dllimport attribute. Since the PE/COFF format doesn't support the kind of relocations that this would require, the MinGW's CRT startup code has an custom framework of their own for manually fixing the missing relocations once module is loaded and the target addresses in the IAT are known. For this to work, the linker (originall in GNU ld) creates a list of remaining references needing fixup, which the runtime processes on startup before handing over control to user code. While this feature is rather controversial, it's one of the main features allowing unix style libraries to be used on windows without any extra porting effort. Some sort of automatic fixing of data imports is also necessary for the itanium C++ ABI on windows (as clang implements it right now) for importing vtable pointers in certain cases, see D43184 for some discussion on that. The runtime pseudo relocation handler supports 8/16/32/64 bit addresses, either PC relative references (like IMAGE_REL_*_REL32*) or absolute references (IMAGE_REL_AMD64_ADDR32, IMAGE_REL_AMD64_ADDR32, IMAGE_REL_I386_DIR32). On linking, the relocation is handled as a relocation against the corresponding IAT slot. For the absolute references, a normal base relocation is created, to update the embedded address in case the image is loaded at a different address. The list of runtime pseudo relocations contains the RVA of the imported symbol (the IAT slot), the RVA of the location the relocation should be applied to, and a size of the memory location. When the relocations are fixed at runtime, the difference between the actual IAT slot value and the IAT slot address is added to the reference, doing the right thing for both absolute and relative references. With this patch alone, things work fine for i386 binaries, and mostly for x86_64 binaries, with feature parity with GNU ld. Despite this, there are a few gotchas: - References to data from within code works fine on both x86 architectures, since their relocations consist of plain 32 or 64 bit absolute/relative references. On ARM and AArch64, references to data doesn't consist of a plain 32 or 64 bit embedded address or offset in the code. On ARMNT, it's usually a MOVW+MOVT instruction pair represented by a IMAGE_REL_ARM_MOV32T relocation, each instruction containing 16 bit of the target address), on AArch64, it's usually an ADRP+ADD/LDR/STR instruction pair with an even more complex encoding, storing a PC relative address (with a range of +/- 4 GB). This could theoretically be remedied by extending the runtime pseudo relocation handler with new relocation types, to support these instruction encodings. This isn't an issue for GCC/GNU ld since they don't support windows on ARMNT/AArch64. - For x86_64, if references in code are encoded as 32 bit PC relative offsets, the runtime relocation will fail if the target turns out to be out of range for a 32 bit offset. - Fixing up the relocations at runtime requires making sections writable if necessary, with the VirtualProtect function. In Windows Store/UWP apps, this function is forbidden. These limitations are addressed by a few later patches in lld and llvm. Differential Revision: https://reviews.llvm.org/D50917 llvm-svn: 340726
2018-08-27 16:43:31 +08:00
# CONTENTS: 140003010 24200040 01000000
[COFF] Omit automatically imported symbols from the symbol table These symbols actually point to the symbol's IAT entry, which obviously is different from the symbol itself (which is imported from a different module and doesn't exist in the current one). Omitting this symbol helps gdb inspect automatically imported symbols, see https://sourceware.org/bugzilla/show_bug.cgi?id=24574 for discussion on the matter. Surprisingly, those extra symbols don't seem to be an issue for gdb when the sources have been built with clang, only with gcc. The actual logic in gdb that this depends on still is unknown, but omitting these symbols from the symbol table is the right thing to do in any case. Differential Revision: https://reviews.llvm.org/D65727 llvm-svn: 367836
2019-08-05 19:57:00 +08:00
# Check that the automatically imported symbol "variable" is not listed in
# the symbol table.
# SYMBOLS-NOT: variable
[LLD] [COFF] Try to fix test errors from 7f0e6c31c255303 on windows Just skip trying to match for the path separator explicitly (instead of making it match either a forward or backwards slash), simplifying the test a little.
2020-05-14 18:46:33 +08:00
# DISABLED: error: automatic dllimport of variable in {{.*}}autoimport-x86.s.tmp.noptrs.obj requires pseudo relocations
[LLD] [COFF] Add options for disabling auto import and runtime pseudo relocs Allow disabling either the full auto import feature, or just forbidding the cases that require runtime fixups. As long as all auto imported variables are referenced from separate .refptr$<name> sections, we can alias them on top of the IAT entries and don't actually need any runtime fixups via pseudo relocations. LLVM generates references to variables in .refptr stubs, if it isn't known that the variable for sure is defined in the same object module. Runtime pseudo relocs are needed if the addresses of auto imported variables are used in constant initializers though. Fixing up runtime pseudo relocations requires the use of VirtualProtect (which is disallowed in WinStore/UWP apps) or VirtualProtectFromApp. To allow any risk of ambiguity, allow rejecting cases that would require this at the linker stage. This adds support for the --disable-runtime-pseudo-reloc and --disable-auto-import options in the MinGW driver (matching GNU ld.bfd) with corresponding lld private options in the COFF driver. Differential Revision: https://reviews.llvm.org/D78923
2020-04-26 05:49:44 +08:00
[COFF] Support MinGW automatic dllimport of data Normally, in order to reference exported data symbols from a different DLL, the declarations need to have the dllimport attribute, in order to use the __imp_<var> symbol (which contains an address to the actual variable) instead of the variable itself directly. This isn't an issue in the same way for functions, since any reference to the function without the dllimport attribute will end up as a reference to a thunk which loads the actual target function from the import address table (IAT). GNU ld, in MinGW environments, supports automatically importing data symbols from DLLs, even if the references didn't have the appropriate dllimport attribute. Since the PE/COFF format doesn't support the kind of relocations that this would require, the MinGW's CRT startup code has an custom framework of their own for manually fixing the missing relocations once module is loaded and the target addresses in the IAT are known. For this to work, the linker (originall in GNU ld) creates a list of remaining references needing fixup, which the runtime processes on startup before handing over control to user code. While this feature is rather controversial, it's one of the main features allowing unix style libraries to be used on windows without any extra porting effort. Some sort of automatic fixing of data imports is also necessary for the itanium C++ ABI on windows (as clang implements it right now) for importing vtable pointers in certain cases, see D43184 for some discussion on that. The runtime pseudo relocation handler supports 8/16/32/64 bit addresses, either PC relative references (like IMAGE_REL_*_REL32*) or absolute references (IMAGE_REL_AMD64_ADDR32, IMAGE_REL_AMD64_ADDR32, IMAGE_REL_I386_DIR32). On linking, the relocation is handled as a relocation against the corresponding IAT slot. For the absolute references, a normal base relocation is created, to update the embedded address in case the image is loaded at a different address. The list of runtime pseudo relocations contains the RVA of the imported symbol (the IAT slot), the RVA of the location the relocation should be applied to, and a size of the memory location. When the relocations are fixed at runtime, the difference between the actual IAT slot value and the IAT slot address is added to the reference, doing the right thing for both absolute and relative references. With this patch alone, things work fine for i386 binaries, and mostly for x86_64 binaries, with feature parity with GNU ld. Despite this, there are a few gotchas: - References to data from within code works fine on both x86 architectures, since their relocations consist of plain 32 or 64 bit absolute/relative references. On ARM and AArch64, references to data doesn't consist of a plain 32 or 64 bit embedded address or offset in the code. On ARMNT, it's usually a MOVW+MOVT instruction pair represented by a IMAGE_REL_ARM_MOV32T relocation, each instruction containing 16 bit of the target address), on AArch64, it's usually an ADRP+ADD/LDR/STR instruction pair with an even more complex encoding, storing a PC relative address (with a range of +/- 4 GB). This could theoretically be remedied by extending the runtime pseudo relocation handler with new relocation types, to support these instruction encodings. This isn't an issue for GCC/GNU ld since they don't support windows on ARMNT/AArch64. - For x86_64, if references in code are encoded as 32 bit PC relative offsets, the runtime relocation will fail if the target turns out to be out of range for a 32 bit offset. - Fixing up the relocations at runtime requires making sections writable if necessary, with the VirtualProtect function. In Windows Store/UWP apps, this function is forbidden. These limitations are addressed by a few later patches in lld and llvm. Differential Revision: https://reviews.llvm.org/D50917 llvm-svn: 340726
2018-08-27 16:43:31 +08:00
.global main
.text
main:
movl variable(%rip), %eax
ret
.data
ptr:
.quad variable
[LLD] [COFF] Add options for disabling auto import and runtime pseudo relocs Allow disabling either the full auto import feature, or just forbidding the cases that require runtime fixups. As long as all auto imported variables are referenced from separate .refptr$<name> sections, we can alias them on top of the IAT entries and don't actually need any runtime fixups via pseudo relocations. LLVM generates references to variables in .refptr stubs, if it isn't known that the variable for sure is defined in the same object module. Runtime pseudo relocs are needed if the addresses of auto imported variables are used in constant initializers though. Fixing up runtime pseudo relocations requires the use of VirtualProtect (which is disallowed in WinStore/UWP apps) or VirtualProtectFromApp. To allow any risk of ambiguity, allow rejecting cases that would require this at the linker stage. This adds support for the --disable-runtime-pseudo-reloc and --disable-auto-import options in the MinGW driver (matching GNU ld.bfd) with corresponding lld private options in the COFF driver. Differential Revision: https://reviews.llvm.org/D78923
2020-04-26 05:49:44 +08:00
.if listptrs==1
[COFF] Support MinGW automatic dllimport of data Normally, in order to reference exported data symbols from a different DLL, the declarations need to have the dllimport attribute, in order to use the __imp_<var> symbol (which contains an address to the actual variable) instead of the variable itself directly. This isn't an issue in the same way for functions, since any reference to the function without the dllimport attribute will end up as a reference to a thunk which loads the actual target function from the import address table (IAT). GNU ld, in MinGW environments, supports automatically importing data symbols from DLLs, even if the references didn't have the appropriate dllimport attribute. Since the PE/COFF format doesn't support the kind of relocations that this would require, the MinGW's CRT startup code has an custom framework of their own for manually fixing the missing relocations once module is loaded and the target addresses in the IAT are known. For this to work, the linker (originall in GNU ld) creates a list of remaining references needing fixup, which the runtime processes on startup before handing over control to user code. While this feature is rather controversial, it's one of the main features allowing unix style libraries to be used on windows without any extra porting effort. Some sort of automatic fixing of data imports is also necessary for the itanium C++ ABI on windows (as clang implements it right now) for importing vtable pointers in certain cases, see D43184 for some discussion on that. The runtime pseudo relocation handler supports 8/16/32/64 bit addresses, either PC relative references (like IMAGE_REL_*_REL32*) or absolute references (IMAGE_REL_AMD64_ADDR32, IMAGE_REL_AMD64_ADDR32, IMAGE_REL_I386_DIR32). On linking, the relocation is handled as a relocation against the corresponding IAT slot. For the absolute references, a normal base relocation is created, to update the embedded address in case the image is loaded at a different address. The list of runtime pseudo relocations contains the RVA of the imported symbol (the IAT slot), the RVA of the location the relocation should be applied to, and a size of the memory location. When the relocations are fixed at runtime, the difference between the actual IAT slot value and the IAT slot address is added to the reference, doing the right thing for both absolute and relative references. With this patch alone, things work fine for i386 binaries, and mostly for x86_64 binaries, with feature parity with GNU ld. Despite this, there are a few gotchas: - References to data from within code works fine on both x86 architectures, since their relocations consist of plain 32 or 64 bit absolute/relative references. On ARM and AArch64, references to data doesn't consist of a plain 32 or 64 bit embedded address or offset in the code. On ARMNT, it's usually a MOVW+MOVT instruction pair represented by a IMAGE_REL_ARM_MOV32T relocation, each instruction containing 16 bit of the target address), on AArch64, it's usually an ADRP+ADD/LDR/STR instruction pair with an even more complex encoding, storing a PC relative address (with a range of +/- 4 GB). This could theoretically be remedied by extending the runtime pseudo relocation handler with new relocation types, to support these instruction encodings. This isn't an issue for GCC/GNU ld since they don't support windows on ARMNT/AArch64. - For x86_64, if references in code are encoded as 32 bit PC relative offsets, the runtime relocation will fail if the target turns out to be out of range for a 32 bit offset. - Fixing up the relocations at runtime requires making sections writable if necessary, with the VirtualProtect function. In Windows Store/UWP apps, this function is forbidden. These limitations are addressed by a few later patches in lld and llvm. Differential Revision: https://reviews.llvm.org/D50917 llvm-svn: 340726
2018-08-27 16:43:31 +08:00
relocs:
.quad __RUNTIME_PSEUDO_RELOC_LIST__
.quad __RUNTIME_PSEUDO_RELOC_LIST_END__
[LLD] [COFF] Add options for disabling auto import and runtime pseudo relocs Allow disabling either the full auto import feature, or just forbidding the cases that require runtime fixups. As long as all auto imported variables are referenced from separate .refptr$<name> sections, we can alias them on top of the IAT entries and don't actually need any runtime fixups via pseudo relocations. LLVM generates references to variables in .refptr stubs, if it isn't known that the variable for sure is defined in the same object module. Runtime pseudo relocs are needed if the addresses of auto imported variables are used in constant initializers though. Fixing up runtime pseudo relocations requires the use of VirtualProtect (which is disallowed in WinStore/UWP apps) or VirtualProtectFromApp. To allow any risk of ambiguity, allow rejecting cases that would require this at the linker stage. This adds support for the --disable-runtime-pseudo-reloc and --disable-auto-import options in the MinGW driver (matching GNU ld.bfd) with corresponding lld private options in the COFF driver. Differential Revision: https://reviews.llvm.org/D78923
2020-04-26 05:49:44 +08:00
.endif