2017-11-28 16:08:37 +08:00
|
|
|
# REQUIRES: x86
|
|
|
|
|
# RUN: llvm-mc -triple=x86_64-windows-gnu -filetype=obj -o %t.obj %s
|
2018-08-30 01:24:10 +08:00
|
|
|
# RUN: lld-link -lldmingw -entry:main %t.obj -out:%t.exe
|
2017-11-28 16:08:37 +08:00
|
|
|
# RUN: llvm-objdump -s %t.exe | FileCheck %s
|
|
|
|
|
|
|
|
|
|
.globl main
|
|
|
|
|
main:
|
|
|
|
|
nop
|
|
|
|
|
|
[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
|
|
|
# Check that these symbols point at the right spots.
|
|
|
|
|
.data
|
|
|
|
|
.quad __CTOR_LIST__
|
|
|
|
|
.quad __DTOR_LIST__
|
|
|
|
|
|
2017-11-28 16:08:37 +08:00
|
|
|
.section .ctors.00005, "w"
|
|
|
|
|
.quad 2
|
|
|
|
|
.section .ctors, "w"
|
|
|
|
|
.quad 1
|
|
|
|
|
.section .ctors.00100, "w"
|
|
|
|
|
.quad 3
|
|
|
|
|
|
|
|
|
|
.section .dtors, "w"
|
2018-08-30 01:24:10 +08:00
|
|
|
.quad 4
|
2017-11-28 16:08:37 +08:00
|
|
|
.section .dtors.00100, "w"
|
2018-08-30 01:24:10 +08:00
|
|
|
.quad 6
|
2017-11-28 16:08:37 +08:00
|
|
|
.section .dtors.00005, "w"
|
2018-08-30 01:24:10 +08:00
|
|
|
.quad 5
|
|
|
|
|
|
|
|
|
|
# Also test that the .CRT section is merged into .rdata
|
2017-11-28 16:08:37 +08:00
|
|
|
|
2018-08-30 01:24:10 +08:00
|
|
|
.section .CRT$XCA, "dw"
|
|
|
|
|
.quad 7
|
|
|
|
|
.quad 8
|
2018-04-05 03:15:55 +08:00
|
|
|
|
2018-08-30 01:24:10 +08:00
|
|
|
# CHECK: Contents of section .rdata:
|
|
|
|
|
# CHECK-NEXT: 140002000 07000000 00000000 08000000 00000000
|
[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
|
|
|
# CHECK-NEXT: 140002010 ffffffff ffffffff 01000000 00000000
|
|
|
|
|
# CHECK-NEXT: 140002020 02000000 00000000 03000000 00000000
|
|
|
|
|
# CHECK-NEXT: 140002030 00000000 00000000 ffffffff ffffffff
|
|
|
|
|
# CHECK-NEXT: 140002040 04000000 00000000 05000000 00000000
|
|
|
|
|
# CHECK-NEXT: 140002050 06000000 00000000 00000000 00000000
|
|
|
|
|
# __CTOR_LIST__ pointing at 0x140002010 and
|
|
|
|
|
# __DTOR_LIST__ pointing at 0x140002038.
|
|
|
|
|
# CHECK-NEXT: Contents of section .data:
|
|
|
|
|
# CHECK-NEXT: 140003000 10200040 01000000 38200040 01000000
|