| 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: | Other | Assignee: | 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
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.
CCing Emil (build system) and Tom (OpenCL) (Bug title should probably be changed to something like "Build failure" or "FTBFS"...) 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 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. (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. 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. 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 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? (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)) 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. 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. (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 :) 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. (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? 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. 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. 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.