<div dir="ltr">I think that making it conditional to Windows and not the MSVC ABI and a static link to the C++ runtime sounds reasonable.<br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 17, 2017 at 4:40 AM, Mateusz Mikuła <span dir="ltr"><<a href="mailto:mati865@gmail.com" target="_blank">mati865@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class="">
<div id="m_7556011901451495183smartTemplate4-template">
<div id="m_7556011901451495183smartTemplate4-template">
<p>Sorry Saleem, looks like this topic got lost on my TODO.<br>
</p>
</div>
Adding `-flto-visibility-public-std` to CC1 helps with undefined
reference to `_imp___cxa*` errors.<br>
<br>
Is it safe enough to make it default flag for MSYS2?<br>
If so I'll patch clang to use it by default.</div>
<br>
<br>
<div id="m_7556011901451495183smartTemplate4-quoteHeader">------ Original Message ------<br>
Subject: Re: [cfe-dev] [MinGW] Clang issues with static libstdc++<br>
Date: Mon, 26 Jun 2017 21:51:19 -0700<br>
To: Mateusz Mikuła, Reid Kleckner, Cfe-dev<br>
From: Saleem Abdulrasool</div>
</span><blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">Building with
`-flto-visibility-public-std` should allow the static build to
work. I think that having support for a static c++ library
makes sense, but need to expose it through a flag to have it
behave like `/MT` vs `/MD`.</div><div><div class="h5">
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">There is a small performance cost for
the thunks, plus binary size benefits for very large binaries
(especially with the BFD linker). IIRC, some versions of lldb
also had trouble with the import thunks when generated by the
BFD linker. I would rather have this be the default and have
an opt-out mechanism rather than the inverse (a la
`-fno-plt`).</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sun, Jun 25, 2017 at 1:20 PM,
Mateusz Mikuła <span dir="ltr"><<a href="mailto:mati865@gmail.com" target="_blank">mati865@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>I've been quite busy lately and lost track on
recent fixes.</div>
<div>Is there any progress on this or should I apply for
bugzilla account and forward it there?</div>
<div>
<div class="m_7556011901451495183h5">
<div><br>
</div>
<div>On Mon, 2017-04-17 at 11∶56 -0700, Reid
Kleckner wrote:</div>
<blockquote type="cite" style="margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex">
<div dir="ltr">The __imp___cxa_begin_catch error
seems related to this code in CodeGenModule::CreateRuntim<wbr>eFunction:
<div>
<div> if (!Local &&
getTriple().isOSBinFormatCOFF(<wbr>)
&&</div>
<div> !getCodeGenOpts().LTOVisibilit<wbr>yPublicStd)
{</div>
<div> const FunctionDecl *FD =
GetRuntimeFunctionDecl(Context<wbr>, Name);</div>
<div> if (!FD ||
FD->hasAttr<DLLImportAttr>()) {</div>
<div> F->setDLLStorageClass(llvm::Gl<wbr>obalValue::DLLImportStorageCla<wbr>ss);</div>
<div> F->setLinkage(llvm::GlobalValu<wbr>e::ExternalLinkage);</div>
<div> }</div>
<div> }</div>
</div>
<div><br>
</div>
<div>This code assumes that all
compiler-referenced runtime functions on COFF
are dllimport, unless we happen to see a
prototype for them during compilation that
says otherwise. Saleem felt we shouldn't rely
on the import thunks that the linker generates
when you reference an imported function but
forget to declare it as dllimport during
compilation. It has some performance benefits,
but it never really bothered me. Most users
don't complain about the extra absolute branch
imposed by the PLT on ELF, and those that do
are getting -fno-plt soon.</div>
<div><br>
</div>
<div>Anyway, you can see the code difference
easily here:</div>
<div><br>
</div>
<div>
<div>$ cat t.cpp</div>
<div>void g();</div>
<div>void f() {</div>
<div> try {</div>
<div> g();</div>
<div> } catch (...) {</div>
<div> }</div>
<div>}</div>
<div><br>
</div>
<div>$ clang -O1 -S t.cpp
--target=x86_64-windows-gnu -o - | grep
__cxa</div>
<div> callq
*__imp___cxa_begin_catch(%rip)</div>
<div> rex64 jmpq
*__imp___cxa_end_catch(%rip) # TAILCALL</div>
<div><br>
</div>
<div>$ gcc -O1 -S t.cpp -o - | grep __cxa</div>
<div> call __cxa_begin_catch</div>
<div> call __cxa_end_catch</div>
<div> .def __cxa_begin_catch;
.scl 2; .type 32; .endef</div>
<div> .def __cxa_end_catch;
.scl 2; .type 32; .endef</div>
</div>
<div><br>
</div>
<div>The other error looks like some kind of
COMDAT disagreement between GCC and Clang that
will require further investigation. It might
relate to our choice to stop using
".text$function_name" for the section.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Apr 17, 2017 at
11:06 AM, Mateusz Mikuła via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span>
wrote:<br>
<blockquote type="cite" style="margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>Clang doesn't work very well with
static libstdc++ build for MinGW
resulting in "multiple definition ..."
or "undefined reference" to the symbols.<br>
</p>
<p>Let's consider following code (removed
includes and main for readability):</p>
<ol>
<li>multiple definition:<br>
<br>
<div style="color:#d4d4d4;background-color:#1e1e1e;font-family:Consolas,'Courier New',monospace;font-weight:normal;font-size:14px;line-height:19px;white-space:pre-wrap"><div><span style="color:#d4d4d4"> std::string a = </span><span style="color:#ce9178">"a"</span><span style="color:#d4d4d4">;</span></div><div><span style="color:#d4d4d4"> std::string b = </span><span style="color:#ce9178">'@'</span><span style="color:#d4d4d4"> + a;</span></div></div>
<br>
This simple code build with `-static`
flag will cause this error:<br>
<br>
D:\msys64\mingw64\lib\gcc\x86_<wbr>64-w64-mingw32\6.3.0\libstdc++<wbr>.a(string-inst.o):(.text$_ZStp<wbr>lIcSt11char_traitsIcESaIcEENSt<wbr>7__cxx1112basic_stringIT_T0_T1<wbr>_EES5_RKS8_[_ZStplIcSt11char_<wbr>traitsIcESaIcEENSt7__<wbr>cxx1112basic_stringIT_T0_T1_<wbr>EES5_RKS8_]+0x0):
multiple definition of
`std::__cxx11::basic_string<ch<wbr>ar,
std::char_traits<char>,
std::allocator<char> >
std::operator+<char,
std::char_traits<char>,
std::allocator<char> >(char,
std::__cxx11::basic_string<cha<wbr>r,
std::char_traits<char>,
std::allocator<char> >
const&)'<br>
D:\msys64\tmp\string-e39e30.o:<wbr>(.text[_ZStplIcSt11char_traits<wbr>IcESaIcEENSt7__cxx1112basic_st<wbr>ringIT_T0_T1_EES5_RKS8_]+0x0):
first defined here<br>
clang++.exe: error: linker command
failed with exit code 1 (use -v to see
invocation)<br>
<br>
</li>
<li>undefined reference<br>
<br>
<div style="color:#d4d4d4;background-color:#1e1e1e;font-family:Consolas,'Courier New',monospace;font-weight:normal;font-size:14px;line-height:19px;white-space:pre-wrap"><div><span style="color:#d4d4d4"> std::u16string b;</span></div></div>
<br>
This time adding `-static` to clang
arguments will cause this error (note:
`__imp___cxa_call_unexpected` exists
only in dynamic libstdc++):<br>
<br>
D:\msys64\tmp\string-7062fd.o:<wbr>(.text[_ZNSt7__cxx1112basic_st<wbr>ringIDsSt11char_traitsIDsESaID<wbr>sEED2Ev]+0x4a):
undefined reference to
`__imp___cxa_call_unexpected'<br>
D:\msys64\tmp\string-7062fd.o:<wbr>(.text[__clang_call_terminate]<wbr>+0x7):
undefined reference to
`__imp___cxa_begin_catch'<br>
D:\msys64\tmp\string-7062fd.o:<wbr>(.text[_ZNSt7__cxx1112basic_st<wbr>ringIDsSt11char_traitsIDsESaID<wbr>sEE10_M_destroyEy]+0x72):
undefined reference to
`__imp___cxa_call_unexpected'<br>
clang++.exe: error: linker command
failed with exit code 1 (use -v to see
invocation)<br>
<br>
</li>
</ol>
<p>It is probably related to the way the
symbols are build into static libstdc++
for MinGW.<br>
Let's take a look at weak symbol from
different test cases:</p>
<ol>
<li>MinGW, dynamic libstdc++:<br>
0000000000000000 I
__imp__ZNSt7__cxx1112basic_str<wbr>ingIcSt11char_traitsIcESaIcEE1<wbr>2_M_constructIPKcEEvT_S8_St20f<wbr>orward_iterator_tag<br>
0000000000000000 T
_ZNSt7__cxx1112basic_stringIcS<wbr>t11char_traitsIcESaIcEE12_M_co<wbr>nstructIPKcEEvT_S8_St20forward<wbr>_iterator_tag<br>
<br>
</li>
<li>MinGW, static libstdc++:<br>
0000000000000000 p
.pdata$_ZNSt7__cxx1112basic_st<wbr>ringIcSt11char_traitsIcESaIcEE<wbr>12_M_constructIPKcEEvT_S8_St20<wbr>forward_iterator_tag<br>
0000000000000000 t
.text$_ZNSt7__cxx1112basic_str<wbr>ingIcSt11char_traitsIcESaIcEE1<wbr>2_M_constructIPKcEEvT_S8_St20f<wbr>orward_iterator_tag<br>
0000000000000000 r
.xdata$_ZNSt7__cxx1112basic_st<wbr>ringIcSt11char_traitsIcESaIcEE<wbr>12_M_constructIPKcEEvT_S8_St20<wbr>forward_iterator_tag<br>
0000000000000000 T
_ZNSt7__cxx1112basic_stringIcS<wbr>t11char_traitsIcESaIcEE12_M_co<wbr>nstructIPKcEEvT_S8_St20forward<wbr>_iterator_tag<br>
<br>
</li>
<li>Linux, static libstdc++:<br>
0000000000000000 W
_ZNSt7__cxx1112basic_stringIcS<wbr>t11char_traitsIcESaIcEE12_M_co<wbr>nstructIPKcEEvT_S8_St20forward<wbr>_iterator_tag</li>
</ol>
<p>This greatly reduces Clang usefulness
on Windows with MinGW.<br>
All responses are welcome.</p>
<p>Best Regards,<br>
Mateusz<br>
</p>
</div>
<br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="m_7556011901451495183gmail_signature" data-smartmail="gmail_signature">Saleem
Abdulrasool<br>
compnerd (at) compnerd (dot) org</div>
</div>
</div></div></div>
</blockquote>
<br>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div>
</div></div>