Commit Graph

4 Commits

Author SHA1 Message Date
Martin Storsjo 7a41693898 [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-14 22:26:59 +00:00
Martin Storsjo cfbbb707f5 [COFF] Merge the .ctors, .dtors and .CRT sections into .rdata for MinGW
There's no point in keeping them as separate sections.

This differs from GNU ld, which places .ctors and .dtors content in
.text (implemented by a built-in linker script). But since the content
only is pointers, there's no need to have it executable.

GNU ld also leaves .CRT separate as its own standalone section.

MSVC merges .CRT into .rdata similarly, with a directive embedded in
an object file in msvcrt.lib or libcmt.lib.

Differential Revision: https://reviews.llvm.org/D51414

llvm-svn: 340940
2018-08-29 17:24:10 +00:00
Hans Wennborg 9a9fc78744 COFF: Layout sections in the same order as link.exe
One place where this seems to matter is to make sure the .rsrc section comes
after .text. The Win32 UpdateResource() function can change the contents of
.rsrc. It will move the sections that come after, but if .text gets moved, the
entry point header will not get updated and the executable breaks. This was
found by a test in Chromium.

Differential Revision: https://reviews.llvm.org/D45260

llvm-svn: 329221
2018-04-04 19:15:55 +00:00
Martin Storsjo f2508f46ca [COFF] Interpret a period as a separator for section suffix just like '$'
This allows grouping all sections like ".ctors.12345" into ".ctors".

For MinGW, the numerical values for such ctors are all zero-padded,
so a lexical sort is good enough.

Differential Revision: https://reviews.llvm.org/D40408

llvm-svn: 319151
2017-11-28 08:08:37 +00:00