Date: Sat, 10 Oct 2015 09:08:46 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Dimitry Andric <dim@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r289072 - in head/contrib: libc++/src llvm/lib/Transforms/Vectorize Message-ID: <20151010060846.GA2257@kib.kiev.ua> In-Reply-To: <201510091821.t99ILjHI054211@repo.freebsd.org> References: <201510091821.t99ILjHI054211@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 09, 2015 at 06:21:45PM +0000, Dimitry Andric wrote: > Author: dim > Date: Fri Oct 9 18:21:45 2015 > New Revision: 289072 > URL: https://svnweb.freebsd.org/changeset/base/289072 > > Log: > Temporarily revert upstream llvm trunk r240144 (by Michael Zolotukhin): > > [SLP] Vectorize for all-constant entries. > > This should fix libc++'s iostream initialization SIGBUSing on amd64, > whenever the global cout symbol is not aligned to 16 bytes. > > Some further explanation: libc++'s iostream.cpp contains the definitions > of std::cout, std::cerr and so on. These global objects are effectively > declared with an alignment of 8 bytes. When an executable is linked > against libc++.so, it can sometimes get a copy of the global object, > which is then at the same alignment. > > However, with clang 3.7.0, the initialization of these global objects > will incorrectly use SSE instructions (e.g. movdqa), whenever the > optimization level is high enough, and SSE is enabled, such as on amd64. > When any of these objects is not aligned to 16 bytes, this will result > in a SIGBUS during iostream initialization. In contrast, clang 3.6.x > and earlier took the 8 byte alignment into consideration, and avoided > SSE for those particular operations. > > After bisecting of upstream changes, I found that the above revision > caused the change of this behavior, so I am reverting it now as a > workaround, while a discussion and test case is being prepared for > upstream. This might be indeed a clang bug, but probably not in the revision which you reverted. Or it might be a libc++ bug. The story, from what I understand from the discussion at some other place, is that the fault occurs on access to the common unaligned symbol. Apparently, ELF does allow to specify alignment of the common symbols, and static linker, when finally allocating .bss space for the object, must obey the requirement. The symbol value for the common symbol must be interpreted as the desired alignment. Could you look up the symbol reference in the .o files (again) and see which alignment is requested ? I think that it is probably clang which should set it to be at least 16 bytes to generate ABI-compliant code.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151010060846.GA2257>