Bug 84242

Summary: FTBFS: libOpenCL.so.1.0.0: ld: .eh_frame_hdr table[5707] FDE at 0000000000c45b8c overlaps table[5708] FDE at 0000000000c45a88
Product: Mesa Reporter: David Kredba <nheghathivhistha>
Component: OtherAssignee: mesa-dev
Status: RESOLVED NOTOURBUG QA Contact:
Severity: normal    
Priority: medium CC: amodra, emil.l.velikov, kai, pedretti.fabio, tstellar
Version: git   
Hardware: x86-64 (AMD64)   
OS: All   
URL: https://bugs.launchpad.net/mesa/+bug/1371636
Whiteboard:
i915 platform: i915 features:
Attachments: Build log showing the FTBFS

Description David Kredba 2014-09-23 11:54:50 UTC
With Gentoo LLVM-3.5 and Mesa-10.3 I cannot link libOpenCL.so.1.0.0 in Mesa-10.3.0-abi_x86_32.x86/src/gallium/targets/opencl with ld message
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2-alpha20140918/../../../../x86_64-pc-linux-gnu/bin/ld: .eh_frame_hdr table[5707] FDE at 0000000000c45b8c overlaps table[5708] FDE at 0000000000c45a88.

gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.2-alpha20140918/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.2-alpha20140918/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.9.2_alpha20140918/work/gcc-4.9-20140918/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.2-alpha20140918 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2-alpha20140918/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.2-alpha20140918 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.2-alpha20140918/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.2-alpha20140918/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2-alpha20140918/include/g++-v4 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.9.2-alpha20140918/python --enable-languages=c,c++,go,objc,obj-c++,fortran,ada --enable-obsolete --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.9.2_alpha20140918' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp --enable-lto --with-cloog --disable-isl-version-check
Thread model: posix
gcc version 4.9.2-alpha20140918 20140919 (prerelease) [gcc-4_9-branch revision 215375] (Gentoo 4.9.2_alpha20140918)

Binutils are today's GIT clone.
I saw bug report at https://bugs.launchpad.net/arb/+bug/1371636 stating this not happens with LLVM 3.4.

Link command:
gmake[3]: Entering directory '/var/tmp/portage/media-libs/mesa-10.3.0/work/Mesa-10.3.0-abi_x86_32.x86/src/gallium/targets/opencl'
/bin/sh ../../../../libtool  --tag=CXX   --mode=link x86_64-pc-linux-gnu-g++ -m32  -flto=4 -fuse-linker-plugin -O2 -pipe -march=core2 -mtune=core2 -mno-3dnow -mno-sse4.2 -mno-avx -mno-xop -mno-fma4 -mno-sse4a -Wall -fno-strict-aliasing -fno-builtin-memcmp  -L/usr/lib32  -no-undefined -version-number 1:0 -Wl,--gc-sections -Wl,--no-undefined -Wl,--version-script=../../../../src/gallium/targets/opencl/opencl.sym -Wl,-flto -fuse-linker-plugin -Wl,--as-needed -Wl,-O2 -Wl,--sort-common -Wl,--hash-style=gnu -O2 -pipe -march=core2 -mtune=core2 -mno-3dnow -mno-sse4.2 -mno-avx -mno-xop -mno-fma4 -mno-sse4a -o libOpenCL.la -rpath /usr/lib32  ../../../../src/gallium/auxiliary/pipe-loader/libpipe_loader_client.la ../../../../src/gallium/state_trackers/clover/libclover.la ../../../../src/gallium/auxiliary/libgallium.la ../../../../src/util/libmesautil.la ../../../../src/gallium/winsys/sw/null/libws_null.la ../../../../src/gallium/winsys/sw/dri/libswdri.la ../../../../src/gallium/winsys/sw/xlib/libws_xlib.la -lX11 -lXext -lXfixes -ldrm  -lxcb-dri2 -lxcb  -ldrm   -ldl -lclangCodeGen -lclangFrontendTool -lclangFrontend -lclangDriver -lclangSerialization -lclangCodeGen -lclangParse -lclangSema -lclangAnalysis -lclangAST -lclangEdit -lclangLex -lclangBasic -lLLVM-3.5.0
libtool: link: x86_64-pc-linux-gnu-g++ -m32  -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2-alpha20140918/../../../../lib32/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2-alpha20140918/32/crtbeginS.o  -Wl,--whole-archive ../../../../src/gallium/auxiliary/pipe-loader/.libs/libpipe_loader_client.a ../../../../src/gallium/state_trackers/clover/.libs/libclover.a ../../../../src/gallium/auxiliary/.libs/libgallium.a ../../../../src/util/.libs/libmesautil.a ../../../../src/gallium/winsys/sw/null/.libs/libws_null.a ../../../../src/gallium/winsys/sw/dri/.libs/libswdri.a ../../../../src/gallium/winsys/sw/xlib/.libs/libws_xlib.a -Wl,--no-whole-archive  -L/usr/lib32 -Wl,--as-needed -lexpat -lX11 -lXext -lXfixes -lxcb-dri2 -lxcb -ldrm -ldl -lclangFrontendTool -lclangFrontend -lclangDriver -lclangSerialization -lclangCodeGen -lclangParse -lclangSema -lclangAnalysis -lclangAST -lclangEdit -lclangLex -lclangBasic -lLLVM-3.5.0 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2-alpha20140918/32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2-alpha20140918/../../../../lib32 -L/lib/../lib32 -L/usr/lib/../lib32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2-alpha20140918 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2-alpha20140918/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2-alpha20140918/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2-alpha20140918/32/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2-alpha20140918/../../../../lib32/crtn.o  -m32 -flto=4 -fuse-linker-plugin -O2 -march=core2 -mtune=core2 -mno-3dnow -mno-sse4.2 -mno-avx -mno-xop -mno-fma4 -mno-sse4a -Wl,--gc-sections -Wl,--no-undefined -Wl,--version-script=../../../../src/gallium/targets/opencl/opencl.sym -Wl,-flto -fuse-linker-plugin -Wl,-O2 -Wl,--sort-common -Wl,--hash-style=gnu -O2 -march=core2 -mtune=core2 -mno-3dnow -mno-sse4.2 -mno-avx -mno-xop -mno-fma4 -mno-sse4a   -Wl,-soname -Wl,libOpenCL.so.1 -o .libs/libOpenCL.so.1.0.0

What more information do you need please?
Comment 1 Kai 2014-09-27 13:17:26 UTC
Created attachment 106957 [details]
Build log showing the FTBFS

I'm seeing the same FTBFS with Mesa from Git HEAD, LLVM 3.6 from SVN.

I've attached the build log from a build in a clean chroot environment (using pbuilder).

My stack is (base: Debian Testing):
libdrm: 2.4.56-1
LLVM: SVN:trunk/r218506 (3.6 snapshot)
libclc: Git:master/5b48f170c8
Mesa: Git:master/c3f17bb18f
GCC: 4.9.1-14 (gcc (Debian 4.9.1-14) 4.9.1)
autoconf: 2.69-8
libtool: 2.4.2-1.10
binutils: 2.24.51.20140903-1


Please let me know, if you need something else.
Comment 2 Kai 2014-09-27 13:21:40 UTC
CCing Emil (build system) and Tom (OpenCL)

(Bug title should probably be changed to something like "Build failure" or "FTBFS"...)
Comment 3 Emil Velikov 2014-09-27 14:11:18 UTC
Building OpenCL works like a charm here. Can you try to establish which (if any) of the following components is responsible - llvm, gcc (*cough* 4.9.2_alpha) binutils or clang.

I'm building it on Archlinux (llvm 3.5.0, gcc 4.9.1 (snapshot 4.9-20140903), binutils 2.24 [1], clang 3.5.0).

[1] The binutils package has a patch which suspiciously looks like it should handle the issue
https://projects.archlinux.org/svntogit/packages.git/plain/trunk/binutils-2.24-shared-pie.patch?h=packages/binutils&id=47bdd59a9967ee8dd2bcc47797855185c6471546
Comment 4 David Kredba 2014-09-27 14:24:31 UTC
I tested it with LLVM 3.4.2 and the same set of gcc-4.9.2 (svn) and binutils (svn) used to open this bug report and all built fine. So for me it looks like that LLVM 3.5.0 came with something changed. Is it not a same name of some function, introduced in LLVM 3.5.0 and present in Mesa before?
It seems to not be LTO issue if Kai really not uses it and with LLVM 3.4.2 it builds with LTO for me.
I checked content of ld/emultempl/elf32.em in my git replica and patch you are reffering to is incorporated.
Comment 5 Emil Velikov 2014-09-27 17:11:36 UTC
(In reply to comment #4)
> I tested it with LLVM 3.4.2 and the same set of gcc-4.9.2 (svn) and binutils
> (svn) used to open this bug report and all built fine.
It may be that llvm 3.5 + mesa is "using" gcc/binutils in a slightly different way.
Can you try using the same versions as the one I've listed ? This way if it works one can start looking for the combination that exhibits the problem.

> So for me it looks
> like that LLVM 3.5.0 came with something changed. Is it not a same name of
> some function, introduced in LLVM 3.5.0 and present in Mesa before?
If the function prototype has changed then a compiler warning is due. Afaict your issue is at a later stage - link time.

> It seems to not be LTO issue if Kai really not uses it and with LLVM 3.4.2
> it builds with LTO for me.
I would recommend disabling LTO until one is able to clearly establish the root cause. After it's sorted you can get it back on for llvm.

> I checked content of ld/emultempl/elf32.em in my git replica and patch you
> are reffering to is incorporated.
I would recommend that you try the patch, before doing anything.
Comment 6 David Kredba 2014-09-27 17:20:49 UTC
patch -p1 < ../../binutils-2.24-shared-pie.patch 
patching file ld/emultempl/elf32.em
Hunk #1 FAILED at 1480.
Hunk #2 FAILED at 1504.
Hunk #3 FAILED at 1620.
3 out of 3 hunks FAILED -- saving rejects to file ld/emultempl/elf32.em.rej
The next patch would create the file ld/testsuite/ld-elf/ehdr_start-shared.d,
which already exists!  Assume -R? [n]
Apply anyway? [n] n
Skipping patch.
1 out of 1 hunk ignored
patching file ld/testsuite/ld-elf/ehdr_start-userdef.d
Reversed (or previously applied) patch detected!  Assume -R? [n] patch: tty read failed: Bad file descriptor
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file ld/testsuite/ld-elf/ehdr_start-userdef.d.rej
patching file ld/testsuite/ld-elf/ehdr_start-weak.d
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file ld/testsuite/ld-elf/ehdr_start-weak.d.rej
patching file ld/testsuite/ld-elf/ehdr_start.d
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file ld/testsuite/ld-elf/ehdr_start.d.rej

So the patch is really included in my binutils. I will try no LTO and if it fails the same way your version of binutils + your patch to binutils.
In the mean time I will try find out if ld.gold can link it and if I can find out what symbol(s)/function(s) is(are) exactly reffered by that frame numbers.
Comment 7 Fabio Pedretti 2014-09-28 08:13:50 UTC
This issue is reproducible without LTO, as reported in the Ubuntu bug. For reference, full build log is here:
https://launchpadlibrarian.net/185286922/buildlog_ubuntu-utopic-i386.mesa_10.4~git1409190730.195891~gd~u_FAILEDTOBUILD.txt.gz
Comment 8 Kai 2014-09-28 13:11:55 UTC
Ok, after trying to build an older Mesa version (Git:HEAD/5a4e0f3873 + patches from Mesa master to build with a recent LLVM 3.6), which I've built successfully in the past, I get the same FTBFS now.

After downgrading binutils to 2.24.51.20140818-1 (the version I've used in the successful build of Mesa 5a4e0f3873), and also downgrading gcc (+ all libraries from the gcc-4.9 package Mesa needs) to 4.9.1-12, because later gcc packages require newer binutils versions, I was able to build even the version I attempted to build yesterday (Mesa c3f17bb18f)

In no build I had LTO activated.

So it seems like this is a bug in binutils/gcc?
Comment 9 Kai 2014-09-28 13:14:29 UTC
(In reply to comment #8)
> Ok, after trying to build an older Mesa version (Git:HEAD/5a4e0f3873 +
> patches from Mesa master to build with a recent LLVM 3.6)

That should have read: (Git:master/5a4e0f3873 + patches from Mesa master to build with a recent LLVM 3.6 (180b152b24, 8f4ee56e49, 58b386dce4 and 4a38b154fd))
Comment 10 David Kredba 2014-09-30 09:31:07 UTC
The same result with gcc 5.0 svn rev. 215679.

.eh_frame_hdr table[5712] FDE at 0000000000c45788 overlaps table[5713] FDE at 0000000000c45684.

Now I will try older binutils with two gcc versions used before.
Comment 11 David Kredba 2014-09-30 12:42:41 UTC
With Gentoo vanilla binutils 2.24-r3 with two slim LTO patches and the patch referred by Emil Velikov in Comment #3

https://projects.archlinux.org/svntogit/packages.git/plain/trunk/binutils-2.24-shared-pie.patch?h=packages/binutils&id=47bdd59a9967ee8dd2bcc47797855185c6471546

it builds fine even with LTO enabled (using a trick with calling configure with LTO turned off and then -fno-lto -fno-use-linker-plugin removed from each Makefile).

So trunk binutils seems to be source of the problem.
I have to start with bisecting them.
Comment 12 Emil Velikov 2014-09-30 15:02:03 UTC
(In reply to comment #11)
> With Gentoo vanilla binutils 2.24-r3 with two slim LTO patches and the patch
> referred by Emil Velikov in Comment #3
> 
> https://projects.archlinux.org/svntogit/packages.git/plain/trunk/binutils-2.
> 24-shared-pie.patch?h=packages/
> binutils&id=47bdd59a9967ee8dd2bcc47797855185c6471546
> 
> it builds fine even with LTO enabled (using a trick with calling configure
> with LTO turned off and then -fno-lto -fno-use-linker-plugin removed from
> each Makefile).
> 
> So trunk binutils seems to be source of the problem.
> I have to start with bisecting them.

Nicely done. I hope that the problem does not end up a sheep in wolf's clothing - i.e. somewhere else. Using gcc+bintutils, to compile a third library, which links to another two compiler(ish) products... there are so many things that can be happening in there.

Thank you for the great initiative :)
Comment 13 Alan Modra 2014-10-03 01:48:03 UTC
I don't believe trunk binutils is the source of the problem.  Trunk binutils (commit ae6c7e33 and aa8f4d1e) is merely letting you know about a case where previous versions of ld silently created binaries with potential runtime failures during exception handling.
Comment 14 Michel Dänzer 2014-10-03 03:22:16 UTC
(In reply to Alan Modra from comment #13)
> Trunk binutils (commit ae6c7e33 and aa8f4d1e) is merely letting you know about
> a case where previous versions of ld silently created binaries with potential
> runtime failures during exception handling.

Thanks. Would you happen to have any pointers to start looking for a solution?
Comment 15 Alan Modra 2014-10-03 03:34:40 UTC
Build libOpenCL.so.1 with -Wl,-noinhibit-exec,-Map,libOpenCl.map and look at the mapfile entries for .eh_frame.  Try to match up with addresses given for the overlapping FDE.  This should give you the object file(s) at fault.  My guess is that further analysis will point at an llvm bug.
Comment 16 Alan Modra 2014-10-03 13:25:50 UTC
It looks like the overlapping FDE error is caused by a bunch of zero address range FDEs in /usr/lib/llvm-3.5/lib/libclangCodeGen.a(CGStmtOpenMP.o).  These do have the potential to cause an exception handling problem at runtime, so ld is correct to complain.  (It might also be reasonable for ld to discard these FDEs.)  I haven't looked into why they are being generated, I'll leave that to someone familiar with that library.  So, not a mesa bug.
Comment 17 Fabio Pedretti 2014-10-05 13:01:02 UTC
Fixed in binutils, see:
http://sourceware.org/bugzilla/show_bug.cgi?id=17447

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.