2018-08-07 05:26:09 +08:00
|
|
|
# REQUIRES: x86
|
|
|
|
|
|
|
|
|
|
# RUN: llvm-mc -triple=x86_64-windows-gnu %s -filetype=obj -o %t1.obj
|
|
|
|
|
# RUN: llvm-mc -triple=x86_64-windows-gnu %S/Inputs/associative-comdat-mingw-2.s -filetype=obj -o %t2.obj
|
|
|
|
|
|
|
|
|
|
# RUN: lld-link -lldmingw -entry:main %t1.obj %t2.obj -out:%t.gc.exe -verbose
|
|
|
|
|
# RUN: llvm-readobj -sections %t.gc.exe | FileCheck %s
|
|
|
|
|
|
|
|
|
|
# CHECK: Sections [
|
|
|
|
|
# CHECK: Section {
|
|
|
|
|
# CHECK: Number: 2
|
|
|
|
|
# CHECK-LABEL: Name: .rdata (2E 72 64 61 74 61 00 00)
|
|
|
|
|
# This is the critical check to show that only *one* definition of
|
[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
|
|
|
# .xdata$foo was retained. This *must* be 0x24 (0x4 for the .xdata
|
|
|
|
|
# section and 0x20 for the .ctors/.dtors headers/ends).
|
2018-08-07 05:26:09 +08:00
|
|
|
# Make sure that no other .xdata sections get included, which would
|
|
|
|
|
# increase the size here.
|
[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: VirtualSize: 0x24
|
2018-08-07 05:26:09 +08:00
|
|
|
|
|
|
|
|
.text
|
|
|
|
|
.def main;
|
|
|
|
|
.scl 2;
|
|
|
|
|
.type 32;
|
|
|
|
|
.endef
|
|
|
|
|
.globl main
|
|
|
|
|
.p2align 4, 0x90
|
|
|
|
|
main:
|
|
|
|
|
call foo
|
|
|
|
|
retq
|
|
|
|
|
|
|
|
|
|
# Defines .text$foo (which has a leader symbol and is referenced like
|
|
|
|
|
# normally), and .xdata$foo (which lacks a leader symbol, which normally
|
|
|
|
|
# would be declared associative to the symbol foo).
|
|
|
|
|
# .xdata$foo should be implicitly treated as associative to foo and brought
|
|
|
|
|
# in, while .xdata$bar, implicitly associative to bar, not included, and
|
|
|
|
|
# .xdata$baz not included since there's no symbol baz.
|
|
|
|
|
|
|
|
|
|
# GNU binutils ld doesn't do this at all, but always includes all .xdata/.pdata
|
|
|
|
|
# comdat sections, even if --gc-sections is used.
|
|
|
|
|
|
|
|
|
|
.section .xdata$foo,"dr"
|
|
|
|
|
.linkonce discard
|
|
|
|
|
.p2align 3
|
|
|
|
|
.long 42
|
|
|
|
|
|
|
|
|
|
.section .xdata$bar,"dr"
|
|
|
|
|
.linkonce discard
|
|
|
|
|
.p2align 3
|
|
|
|
|
.long 43
|
|
|
|
|
|
|
|
|
|
.section .xdata$baz,"dr"
|
|
|
|
|
.linkonce discard
|
|
|
|
|
.p2align 3
|
|
|
|
|
.long 44
|
|
|
|
|
|
|
|
|
|
.def foo;
|
|
|
|
|
.scl 2;
|
|
|
|
|
.type 32;
|
|
|
|
|
.endef
|
|
|
|
|
.section .text$foo,"xr",discard,foo
|
|
|
|
|
.globl foo
|
|
|
|
|
.p2align 4
|
|
|
|
|
foo:
|
|
|
|
|
ret
|
|
|
|
|
|
|
|
|
|
.def bar;
|
|
|
|
|
.scl 2;
|
|
|
|
|
.type 32;
|
|
|
|
|
.endef
|
|
|
|
|
.section .text$bar,"xr",discard,bar
|
|
|
|
|
.globl bar
|
|
|
|
|
.p2align 4
|
|
|
|
|
bar:
|
|
|
|
|
ret
|