[llvm-bugs] [Bug 39754] Mingw-w64 runtime failure

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=39754

Martin Storsjö <martin at martin.st> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #15 from Martin Storsjö <martin at martin.st> ---
(In reply to Edward Diener from comment #14)
> I do not know how you can not reproduce this problem. Do you have
> mingw-w64/gcc-7.3 installed using the installer from the link
> http://sourceforge.net/projects/mingw-w64/files/
> Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/installer/
> mingw-w64-install.exe/download, and choosing:

No, I was testing with gcc/binutils of the same version installed within msys2
instead. By installing it from there, I can reproduce it.

The map file you posted also shows the issue quite clearly:

*(SORT_BY_NAME(.rdata$*))
 .rdata$__ZN5boost9parameter7keywordIN4soup3tag2kwEE8instanceE
                0x004042c0        0x1 test_clang7.obj
                0x004042c0               
boost::parameter::keyword<soup::tag::kw>::instance
 .rdata$__ZN5boost9parameter7keywordIN4soup3tag6unusedEE8instanceE
                0x004042c1        0x1 test_clang7.obj
                0x004042c1               
boost::parameter::keyword<soup::tag::unused>::instance
 .rdata$__ZZNK5boost17integral_constantIbLb0EEcvRKN4mpl_5bool_ILb0EEEEvE4data
                0x004042c2        0x4 test_clang7.obj
                0x004042c2                boost::integral_constant<bool,
false>::operator mpl_::bool_<false> const&() const::data
                0x004042c8                . = ALIGN (0x4)
 *fill*         0x004042c6        0x2 
                0x004042c8                __rt_psrelocs_start = .
 *(.rdata_runtime_pseudo_reloc)
 .rdata_runtime_pseudo_reloc
                0x004042c8       0x18 rtr000000.o
                0x004042e0                __rt_psrelocs_end = .
                0x00000018                __rt_psrelocs_size =
(__rt_psrelocs_end - __rt_psrelocs_start)
                0x004042e0                ___RUNTIME_PSEUDO_RELOC_LIST_END__ =
.
                0x004042e0                __RUNTIME_PSEUDO_RELOC_LIST_END__ = .
                0x004042c8                ___RUNTIME_PSEUDO_RELOC_LIST__ = (. -
__rt_psrelocs_size)
                0x004042c8                __RUNTIME_PSEUDO_RELOC_LIST__ = (. -
__rt_psrelocs_size)

The clang produced object files contains a few sections named
.rdata$<symbolname> containing 1, 1, 4 and 2 bytes of data each. These sections
have no alignment requirements in themselves, and thus can be packed tightly.
Absolutely nothing incorrect/buggy about that.

Since your map file was built with a patched version of ld, there's a fill of 2
bytes to align things before __rt_psrelocs_start. Before that fix in binutils,
binutils behaviour was buggy as it recorded the address in __rt_psrelocs_start
without doing any alignment, while the linker synthesized contents (in 0x18
rtr000000.o) was aligned. That was the only bug involved here.

Nothing more to investigate wrt LLVM/clang here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20181202/76e0e6d9/attachment.html>