On 08/05/14 01:07, Keith Clifford wrote:
This is just an update about the Seg Fault that I had building PPL last week. The issue is in the mingw compiler under certain circumstances which are described below if you're interested and in the attached files. The compiler and your test in the configure script indicate that the compiler supports weak symbols but it really doesn't under specific circumstances which the PPL build found. Anyway its in Cygwin's hands now.
Hello Keith.
thanks for the update. Please keep me posted. I am thinking that, even if Cygwin people fixes the issue, this will not happen until some time. Perhaps we should change the configure script so as to perform a more precise detection. What do you think? Thanks again,
Roberto
-----Original Message----- From: Keith Clifford [mailto:kclifford@tranaptic.ca] Sent: August 4, 2014 2:10 PM To: 'cygwin@cygwin.com' Subject: seg fault on override of a weak symbol in g++
Hi, I was trying to build the ppl 1.1 library and got a seg fault when running one of the tests. I've narrowed it down to the attached test case.
System: CYGWIN_NT-6.1 Keith-PC 1.7.31(0.272/5/3) 2014-07-25 11:26 x86_64 Cygwin
Both the following GCC's exhibit the problem Cygwin: Using built-in specs. COLLECT_GCC=i686-pc-mingw32-g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-mingw32/4.7.3/lto-wrapper.exe Target: i686-pc-mingw32 Configured with: /usr/src/packages/mingw-gcc/64/mingw-gcc-4.7.3-1/src/gcc-4.7.3/configure --srcdir=/usr/src/packages/mingw-gcc/64/mingw-gcc-4.7.3-1/src/gcc-4.7.3 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --datarootdir=/usr/share --docdir=/usr/share/doc/mingw-gcc -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=i686-pc-mingw32 --without-libiconv-prefix --without-libintl-prefix --with-sysroot=/usr/i686-pc-mingw32/sys-root --with-build-sysroot=/usr/i686-pc-mingw32/sys-root --enable-languages=c,c++,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --disable-build-poststage1-with-cxx --enable-version-specific-runtime-libs --disable-multilib --enable-decimal-float=bid --disable-werror --enable-lto Thread model: win32 gcc version 4.7.3 (GCC)
Using built-in specs. COLLECT_GCC=i686-w64-mingw32-g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-w64-mingw32/4.8.3/lto-wrapper.exe Target: i686-w64-mingw32 Configured with: /cygdrive/i/szsz/tmpp/cygwin64/mingw64-i686/mingw64-i686-gcc-4.8.3-1/src/gcc -4.8.3/configure --srcdir=/cygdrive/i/szsz/tmpp/cygwin64/mingw64-i686/mingw64-i686-gcc-4.8.3- 1/src/gcc-4.8.3 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --libdir=/usr/lib --datarootdir=/usr/share --docdir=/usr/share/doc/mingw64-i686-gcc --htmldir=/usr/share/doc/mingw64-i686-gcc/html -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=i686-w64-mingw32 --without-libiconv-prefix --without-libintl-prefix --with-sysroot=/usr/i686-w64-mingw32/sys-root --with-build-sysroot=/usr/i686-w64-mingw32/sys-root --disable-multilib --disable-win32-registry --enable-languages=c,ada,c++,fortran,lto,objc,obj-c++ --enable-fully-dynamic-strings --enable-graphite --enable-libgomp --enable-libquadmath --enable-libquadmath-support --enable-libssp --enable-version-specific-runtime-libs --with-dwarf2 --with-gnu-ld --with-gnu-as --with-tune=generic --with-cloog-include=/usr/include/cloog-isl --with-system-zlib --libexecdir=/usr/lib Thread model: win32 gcc version 4.8.3 (GCC)
When built with the default Cygwin compiler the problem doesn't occur. Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/lto-wrapper.exe Target: x86_64-pc-cygwin Configured with: /cygdrive/i/szsz/tmpp/cygwin64/gcc/gcc-4.8.3-2/src/gcc-4.8.3/configure --srcdir=/cygdrive/i/szsz/tmpp/cygwin64/gcc/gcc-4.8.3-2/src/gcc-4.8.3 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --libdir=/usr/lib --datarootdir=/usr/share --docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin --without-libiconv-prefix --without-libintl-prefix --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --enable-bootstrap --disable-__cxa_atexit --with-dwarf2 --with-tune=generic --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite --enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm --enable-libquadmath --enable-libquadmath-support --enable-libssp --enable-libada --enable-libgcj-sublibs --disable-java-awt --disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix --without-libintl-prefix --with-system-zlib --libexecdir=/usr/lib Thread model: posix gcc version 4.8.3 (GCC)
In the attached files in weak.cpp if the line static ios_base::Init __ioinit; is commented out the seg fault doesn't occur. Doing a disassembly of weak.o (objdump -d weak.o) shows that the call includes a nonzero offset that gets applied when the weak symbol is overridden by the function in strong.o. The offset is zero if the above mentioned line is commented out.
Regards, Keith