after emerge =sys-devel/llvm-3.0-r1, i got, * Messages for package sys-devel/llvm-3.0-r1: * Package: sys-devel/llvm-3.0-r1 * Repository: gentoo * Maintainer: voyageur@gentoo.org * USE: elibc_glibc kernel_linux libffi ppc userland_GNU vim-syntax * FEATURES: ccache sandbox userpriv usersandbox * Package: sys-devel/llvm-3.0-r1 * Repository: gentoo * Maintainer: voyageur@gentoo.org * USE: elibc_glibc kernel_linux libffi ppc userland_GNU vim-syntax * FEATURES: ccache sandbox userpriv usersandbox * Fixing install dirs * Fixing rpath and CFLAGS * Applying llvm-2.6-commandguide-nops.patch ... * Applying llvm-2.9-nodoctargz.patch ... * Applying llvm-3.0-ocaml_install.patch ... * Applying llvm-3.0-PPC_macro.patch ... * Applying llvm-3.0-gold_LTO_link.patch ... * QA Notice: The following files contain runtime text relocations * Text relocations force the dynamic linker to perform extra * work at startup, waste system resources, and may pose a security * risk. On some architectures, the code may not even function * properly, if at all. * For more information, see http://hardened.gentoo.org/pic-fix-guide.xml * Please include the following list of files in your report: * TEXTREL usr/lib/llvm/libLLVM-3.0.so Reproducible: Always Steps to Reproduce: 1. emerge =sys-devel/llvm-3.0-r1 Actual Results: TEXTREL QA appears. Expected Results: no TEXTREL QA. a while ago, i got ton of TEXTREL b/c broken binutils (see Bug 392645). is this a arch-specific/toolchain related bug? FYI, my emerge --info is, Portage 2.1.10.46 (default/linux/powerpc/ppc32/10.0, gcc-4.5.3, glibc-2.14.1-r2, 3.2.5-gentoo ppc) ================================================================= System uname: Linux-3.2.5-gentoo-ppc-7447A,_altivec_supported-with-gentoo-2.1 Timestamp of tree: Mon, 13 Feb 2012 04:45:01 +0000 ccache version 3.1.7 [enabled] app-shells/bash: 4.2_p20 dev-lang/python: 2.7.2-r3, 3.2.2 dev-util/ccache: 3.1.7 dev-util/cmake: 2.8.7-r3 dev-util/pkgconfig: 0.26 sys-apps/baselayout: 2.1 sys-apps/openrc: 0.9.8.4 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.68 sys-devel/automake: 1.11.3 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.5.3-r2 sys-devel/gcc-config: 1.5-r2 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r3 sys-kernel/linux-headers: 3.2 (virtual/os-headers) sys-libs/glibc: 2.14.1-r2 Repositories: gentoo x-crossdev hiyuh ACCEPT_KEYWORDS="ppc ~ppc" ACCEPT_LICENSE="* -@EULA" CBUILD="powerpc-unknown-linux-gnu" CFLAGS="-Os -mcpu=G4 -mtune=G4 -maltivec -mabi=altivec -Wall" CHOST="powerpc-unknown-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-Os -mcpu=G4 -mtune=G4 -maltivec -mabi=altivec -Wall" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--quiet=n --quiet-build=n" FEATURES="assume-digests binpkg-logs ccache collision-protect distlocks ebuild-locks fixlafiles news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox" FFLAGS="" GENTOO_MIRRORS=" http://gentoo.channelx.biz/ http://gentoo.gg3.net/ ftp://gg3.net/pub/linux/gentoo/ ftp://ftp.iij.ad.jp/pub/linux/gentoo/ http://ftp.iij.ad.jp/pub/linux/gentoo/ rsync://ftp.iij.ad.jp/pub/linux/gentoo/ http://ftp.jaist.ac.jp/pub/Linux/Gentoo/ rsync://ftp.jaist.ac.jp/pub/Linux/Gentoo/ ftp://ftp.jaist.ac.jp/pub/Linux/Gentoo/ " LANG="ja_JP.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en ja" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/overlay/crossdev /usr/local/overlay/hiyuh" SYNC="rsync://rsync.jp.gentoo.org/gentoo-portage" USE="X acl altivec bash-completion berkdb bzip2 caps cjk cli cracklib crypt cxx dri fontconfig fortran gdbm gif gpm gtk3 iconv icu jbig jpeg jpeg2k lzma modules mudflap ncurses nls nptl nptlonly opengl openmp png ppc readline session ssl svg sysfs t1lib tcpd threads tiff truetype unicode vim-syntax xcb xft xorg zlib" ALSA_CARDS="aoa aoa-fabric-layout aoa-onyx aoa-soundbus aoa-soundbus-i2s aoa-tas aoa-toonie" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LINGUAS="en ja" USERLAND="GNU" VIDEO_CARDS="fbdev radeon r200" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Thanks for the report! All clear here on amd64 (no textrel), but as I do not have a ppc, I can not say if this is the same problem as in #392645 CC-ing toolchain for opinion
FYI, using -O2 instead of -Os doesn't solve this issue. Also, i tried 9999 (llvm-3.0-PPC_macro.patch is required to compile, btw), but no joy. w/ C{,XX}FLAGS="-ggdb -O2 ..." + FEATURES="splitdebug noclean" for debugging, i got, $ scanelf -qT /usr/lib/llvm/libLLVM-3.0.so libLLVM-3.0.so: PPCCompilationCallbackC [0x1D86F8] in (optimized out: previous PPC32CompilationCallback) [0x1D869C] /usr/lib/llvm/libLLVM-3.0.so $ objdump -d /usr/lib/llvm/libLLVM-3.0.so [SNIP] 57224 001d869c <PPC32CompilationCallback>: 57225 1d869c:>--7c 08 02 a6 >---mflr r0 57226 1d86a0:>--90 01 00 04 >---stw r0,4(r1) 57227 1d86a4:>--94 21 ff 98 >---stwu r1,-104(r1) 57228 1d86a8:>--91 41 00 64 >---stw r10,100(r1) 57229 1d86ac:>--91 21 00 60 >---stw r9,96(r1) 57230 1d86b0:>--91 01 00 5c >---stw r8,92(r1) 57231 1d86b4:>--90 e1 00 58 >---stw r7,88(r1) 57232 1d86b8:>--90 c1 00 54 >---stw r6,84(r1) 57233 1d86bc:>--90 a1 00 50 >---stw r5,80(r1) 57234 1d86c0:>--90 81 00 4c >---stw r4,76(r1) 57235 1d86c4:>--90 61 00 48 >---stw r3,72(r1) 57236 1d86c8:>--d9 01 00 40 >---stfd f8,64(r1) 57237 1d86cc:>--d8 e1 00 38 >---stfd f7,56(r1) 57238 1d86d0:>--d8 c1 00 30 >---stfd f6,48(r1) 57239 1d86d4:>--d8 a1 00 28 >---stfd f5,40(r1) 57240 1d86d8:>--d8 81 00 20 >---stfd f4,32(r1) 57241 1d86dc:>--d8 61 00 18 >---stfd f3,24(r1) 57242 1d86e0:>--d8 41 00 10 >---stfd f2,16(r1) 57243 1d86e4:>--d8 21 00 08 >---stfd f1,8(r1) 57244 1d86e8:>--7c 03 03 78 >---mr r3,r0 57245 1d86ec:>--80 a1 00 68 >---lwz r5,104(r1) 57246 1d86f0:>--80 85 00 04 >---lwz r4,4(r5) 57247 1d86f4:>--38 a0 00 00 >---li r5,0 57248 1d86f8:>--48 00 00 01 >---bl 1d86f8 <PPC32CompilationCallback+0x5c> 57249 1d86fc:>--7c 69 03 a6 >---mtctr r3 [SNIP] line 57248 looks really weird to me, isn't it "ME: bl ME"? and after source dive, i realized above snippet is compiled from lib/Target/PowerPC/PPCJITInfo.cpp: [SNIP] 80 asm( 81 ".text\n" 82 ".align 2\n" 83 ".globl _PPC32CompilationCallback\n" 84 "_PPC32CompilationCallback:\n" 85 // Make space for 8 ints r[3-10] and 13 doubles f[1-13] and the 86 // FIXME: need to save v[0-19] for altivec? 87 // FIXME: could shrink frame 88 // Set up a proper stack frame 89 // FIXME Layout 90 // PowerPC32 ABI linkage - 24 bytes 91 // parameters - 32 bytes 92 // 13 double registers - 104 bytes 93 // 8 int registers - 32 bytes 94 "mflr r0\n" 95 "stw r0, 8(r1)\n" 96 "stwu r1, -208(r1)\n" 97 // Save all int arg registers 98 "stw r10, 204(r1)\n" "stw r9, 200(r1)\n" 99 "stw r8, 196(r1)\n" "stw r7, 192(r1)\n" 100 "stw r6, 188(r1)\n" "stw r5, 184(r1)\n" 101 "stw r4, 180(r1)\n" "stw r3, 176(r1)\n" 102 // Save all call-clobbered FP regs. 103 "stfd f13, 168(r1)\n" "stfd f12, 160(r1)\n" 104 "stfd f11, 152(r1)\n" "stfd f10, 144(r1)\n" 105 "stfd f9, 136(r1)\n" "stfd f8, 128(r1)\n" 106 "stfd f7, 120(r1)\n" "stfd f6, 112(r1)\n" 107 "stfd f5, 104(r1)\n" "stfd f4, 96(r1)\n" 108 "stfd f3, 88(r1)\n" "stfd f2, 80(r1)\n" 109 "stfd f1, 72(r1)\n" 110 // Arguments to Compilation Callback: 111 // r3 - our lr (address of the call instruction in stub plus 4) 112 // r4 - stub's lr (address of instruction that called the stub plus 4) 113 // r5 - is64Bit - always 0. 114 "mr r3, r0\n" 115 "lwz r2, 208(r1)\n" // stub's frame 116 "lwz r4, 8(r2)\n" // stub's lr 117 "li r5, 0\n" // 0 == 32 bit 118 "bl _PPCCompilationCallbackC\n" 119 "mtctr r3\n" [SNIP] 294 extern "C" void *PPCCompilationCallbackC(unsigned *StubCallAddrPlus4, 295 unsigned *OrigCallAddrPlus4, 296 bool is64Bit) { [SNIP] 339 } [SNIP] but i don't understand why "bl _PPCCompilationCallbackC\n" is assembled to "1d86f8:　bl 1d86f8 <PPC32CompilationCallback+0x5c>"... maybe, i need more ppc power. :)
(In reply to comment #2) > and after source dive, i realized above snippet is compiled from > lib/Target/PowerPC/PPCJITInfo.cpp: > > [SNIP] > 80 asm( > 81 ".text\n" > 82 ".align 2\n" > 83 ".globl _PPC32CompilationCallback\n" > 84 "_PPC32CompilationCallback:\n" > 85 // Make space for 8 ints r[3-10] and 13 doubles f[1-13] and the > 86 // FIXME: need to save v[0-19] for altivec? > 87 // FIXME: could shrink frame > 88 // Set up a proper stack frame > 89 // FIXME Layout > 90 // PowerPC32 ABI linkage - 24 bytes > 91 // parameters - 32 bytes > 92 // 13 double registers - 104 bytes > 93 // 8 int registers - 32 bytes > 94 "mflr r0\n" > 95 "stw r0, 8(r1)\n" > 96 "stwu r1, -208(r1)\n" > 97 // Save all int arg registers > 98 "stw r10, 204(r1)\n" "stw r9, 200(r1)\n" > 99 "stw r8, 196(r1)\n" "stw r7, 192(r1)\n" > 100 "stw r6, 188(r1)\n" "stw r5, 184(r1)\n" > 101 "stw r4, 180(r1)\n" "stw r3, 176(r1)\n" > 102 // Save all call-clobbered FP regs. > 103 "stfd f13, 168(r1)\n" "stfd f12, 160(r1)\n" > 104 "stfd f11, 152(r1)\n" "stfd f10, 144(r1)\n" > 105 "stfd f9, 136(r1)\n" "stfd f8, 128(r1)\n" > 106 "stfd f7, 120(r1)\n" "stfd f6, 112(r1)\n" > 107 "stfd f5, 104(r1)\n" "stfd f4, 96(r1)\n" > 108 "stfd f3, 88(r1)\n" "stfd f2, 80(r1)\n" > 109 "stfd f1, 72(r1)\n" > 110 // Arguments to Compilation Callback: > 111 // r3 - our lr (address of the call instruction in stub plus 4) > 112 // r4 - stub's lr (address of instruction that called the stub plus > 4) > 113 // r5 - is64Bit - always 0. > 114 "mr r3, r0\n" > 115 "lwz r2, 208(r1)\n" // stub's frame > 116 "lwz r4, 8(r2)\n" // stub's lr > 117 "li r5, 0\n" // 0 == 32 bit > 118 "bl _PPCCompilationCallbackC\n" > 119 "mtctr r3\n" > [SNIP] sorry, my brain mis-preprocessed, this should be line 147-182 in same file: [SNIP] 147 asm( 148 ".text\n" 149 ".align 2\n" 150 ".globl PPC32CompilationCallback\n" 151 "PPC32CompilationCallback:\n" 152 // Make space for 8 ints r[3-10] and 8 doubles f[1-8] and the 153 // FIXME: need to save v[0-19] for altivec? 154 // FIXME: could shrink frame 155 // Set up a proper stack frame 156 // FIXME Layout 157 // 8 double registers - 64 bytes 158 // 8 int registers - 32 bytes 159 "mflr 0\n" 160 "stw 0, 4(1)\n" 161 "stwu 1, -104(1)\n" 162 // Save all int arg registers 163 "stw 10, 100(1)\n" "stw 9, 96(1)\n" 164 "stw 8, 92(1)\n" "stw 7, 88(1)\n" 165 "stw 6, 84(1)\n" "stw 5, 80(1)\n" 166 "stw 4, 76(1)\n" "stw 3, 72(1)\n" 167 // Save all call-clobbered FP regs. 168 "stfd 8, 64(1)\n" 169 "stfd 7, 56(1)\n" "stfd 6, 48(1)\n" 170 "stfd 5, 40(1)\n" "stfd 4, 32(1)\n" 171 "stfd 3, 24(1)\n" "stfd 2, 16(1)\n" 172 "stfd 1, 8(1)\n" 173 // Arguments to Compilation Callback: 174 // r3 - our lr (address of the call instruction in stub plus 4) 175 // r4 - stub's lr (address of instruction that called the stub plus 4) 176 // r5 - is64Bit - always 0. 177 "mr 3, 0\n" 178 "lwz 5, 104(1)\n" // stub's frame 179 "lwz 4, 4(5)\n" // stub's lr 180 "li 5, 0\n" // 0 == 32 bit 181 "bl PPCCompilationCallbackC\n" 182 "mtctr 3\n" [SNIP]
(In reply to comment #2) scanelf doesn't (currently) handle splitdebug
Created attachment 304581 [details, diff] experimental GNU-stack patch for PPCJITInfo.cpp i don't know whether this is correct fix or not, though. using w/ this patch, TEXTREL QA doesn't appear.
(In reply to comment #5) no, i don't think that's right. pretty sure you already found the source of the problem in that asm code: 118 "bl _PPCCompilationCallbackC\n" that's a direct jump that doesn't go through the PLT. you can't do that in PIC. try this patch instead: #ifdef __PIC__ "bl _PPCCompilationCallbackC@plt\n" #else "bl _PPCCompilationCallbackC\n" #endif
Created attachment 306671 [details, diff] patch to append @plt to all of "bl _PPCCompilationCallbackC" and variants attached patch i used w/ sys-devel/llvm-9999 (r153425).
(In reply to comment #6) > try this patch instead: > > #ifdef __PIC__ > "bl _PPCCompilationCallbackC@plt\n" > #else > "bl _PPCCompilationCallbackC\n" > #endif I tried (see attached new pacth) and there is no TEXTREL QA. FYI, w/ great helping by chapuni (an upstream llvm dev), I finally realized that altivec enabled llvm is broken. "append-flags -mno-altivec -mabi=no-altivec" might be required on ppc. I did that in /etc/portage/package.env ATM. NOTE, altivec related flags are also automatically enabled/disabled by -mcpu or so, simple replace-flags/strip-flags does not work correctly.
Comment on attachment 306671 [details, diff] patch to append @plt to all of "bl _PPCCompilationCallbackC" and variants the PLT concept is largely ELF specific. so you might want to only update the code branches that are for ELF. seems like there's other random targets sprinkled throughout here which you don't want to update ... at any rate, looks like it's a bug in llvm, and we've found the root cause, so there's nothing left here for toolchain@g.o ...
(In reply to comment #9) > Comment on attachment 306671 [details, diff] [details, diff] > patch to append @plt to all of "bl _PPCCompilationCallbackC" and variants The patch is wrong, since it will break both darwin and windows. What if you just declare PPCCompilationCallbackC static? The the function will be local and thus one won't need to produce the call via PLT. Will this fix the problem?
FYI, i post an email to LLVMdev ML. http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-March/048491.html and i opened a bug on upstrean bugzilla as per Hal Finkel requested at the ML. http://llvm.org/bugs/show_bug.cgi?id=12422
Created attachment 307443 [details, diff] patch to declare PPCCompilationCallbackC static
(In reply to comment #10) > The patch is wrong, since it will break both darwin and windows. What if you > just declare PPCCompilationCallbackC static? The the function will be local > and thus one won't need to produce the call via PLT. Will this fix the > problem? new patch is attached, but it doesn't work on final link. w/ sys-devel/llvm-9999, i got, llvm[1]: Linking Release Shared Library libLLVM-3.1svn.so powerpc-unknown-linux-gnu-g++ -I/var/tmp/portage/sys-devel/llvm-9999/work/llvm-9999/include -I/var/tmp/portage/sys-devel/llvm-9999/work/llvm-9999/tools/llvm-shlib -DNDEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fvisibility-inlines-hidden -fno-exceptions -fPIC -Woverloaded-virtual -Wcast-qual -O2 -mcpu=G4 -mtune=G4 -maltivec -mabi=altivec -Wall -fno-strict-aliasing -mno-altivec -mabi=no-altivec -ggdb -Wl,-R -Wl,'$ORIGIN' -L/var/tmp/portage/sys-devel/llvm-9999/work/llvm-9999/Release/lib -L/var/tmp/portage/sys-devel/llvm-9999/work/llvm-9999/Release/lib -Wl,-O1 -Wl,--as-needed -Wl,-O1 -Wl,--as-needed -Wl,-O1 -Wl,--as-needed -Wl,-O1 -Wl,--as-needed -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings -shared -o /var/tmp/portage/sys-devel/llvm-9999/work/llvm-9999/Release/lib/libLLVM-3.1svn.so \ -Wl,--whole-archive -lLLVMPowerPCCodeGen -lLLVMMCJIT -lLLVMScalarOpts -lLLVMJIT -lLLVMMCDisassembler -lLLVMSupport -lLLVMSelectionDAG -lLLVMAnalysis -lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMLinker -lLLVMipo -lLLVMMC -lLLVMCore -lLLVMPowerPCAsmPrinter -lLLVMVectorize -lLLVMMCParser -lLLVMInterpreter -lLLVMipa -lLLVMBitWriter -lLLVMAsmPrinter -lLLVMBitReader -lLLVMTransformUtils -lLLVMObject -lLLVMCodeGen -lLLVMAsmParser -lLLVMInstCombine -lLLVMPowerPCInfo -lLLVMArchive -lLLVMTarget -lLLVMInstrumentation -lLLVMDebugInfo -lLLVMPowerPCDesc -Wl,--no-whole-archive -Wl,--no-undefined -Wl,--soname,libLLVM-3.1svn.so -lpthread -lffi -ldl -lm /var/tmp/portage/sys-devel/llvm-9999/work/llvm-9999/Release/lib/libLLVMPowerPCCodeGen.a(PPCJITInfo.o): In function `PPC32CompilationCallback': PPCJITInfo.cpp:(.text+0x5c): undefined reference to `PPCCompilationCallbackC' /usr/lib/gcc/powerpc-unknown-linux-gnu/4.5.3/../../../../powerpc-unknown-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in a shared object. collect2: ld returned 1 exit status make[1]: *** [/var/tmp/portage/sys-devel/llvm-9999/work/llvm-9999/Release/lib/libLLVM-3.1svn.so] Error 1 make[1]: Leaving directory `/var/tmp/portage/sys-devel/llvm-9999/work/llvm-9999/tools/llvm-shlib' make: *** [all] Error 1
(In reply to comment #10) > The patch is wrong, since it will break both darwin and windows. btw, if i create new PLT patch only for ELF, it won't break?
(In reply to comment #13) > new patch is attached, but it doesn't work on final link. > w/ sys-devel/llvm-9999, i got, Right, you removed extern "C". Please check how this is done in X86JITInfo.cpp for example. The function is called X86CompilationCallback2 there.
Created attachment 307587 [details, diff] patch to declare PPCCompilationCallbackC static (revised)
(In reply to comment #15) > Right, you removed extern "C". Please check how this is done in > X86JITInfo.cpp for example. The function is called X86CompilationCallback2 > there. revised patch is attached. and I confirmed this fix works fine.
FYI, Anton committed the revised patch into upstream svn trunk. http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-April/048573.html http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/PowerPC/PPCJITInfo.cpp?r1=133059&r2=153938&pathrev=153938
Sorry for the delay, and thanks for your work on this bug! I have added the patch in current 3.0-r2 (I have a revbump with some cleanups in progress, but at least your patch is in now)
