Description of problem: hpiod requires execmem on ppc platforms SELinux will not allow it to start It should not require this and probably has a build problem http://people.redhat.com/drepper/selinux-mem.html
[root@dhcp83-81 sbin]# eu-readelf -l /usr/lib/libstdc++.so.6 | grep LOAD LOAD 0x000000 0x00560000 0x00560000 0x108af8 0x108af8 R E 0x10000 LOAD 0x109448 0x00679448 0x00679448 0x0061cc 0x00b9e8 RWE 0x10000 [root@dhcp83-81 sbin]# rpm -qf /usr/lib/libstdc++.so.6 libstdc++-4.1.0-2
Tim do you have any idea what port it is trying to connect to?
.got and .plt contain executable code and are in the data segment on ppc32, and this appears to be by design. I found this comment in binutils-*/bfd/elf32-ppc.c: /* The powerpc .got has a blrl instruction in it. Mark it executable. */ What I still haven't figured out is why there are shared libraries that do have a GOT and a PLT, but do not get the executable bit set for them. I noticed libstdc++ and libgcj do get the bit set, whereas libgcc_s and libgcjawt don't.
Problem narrowed down to eh_globals.o in libsupc++, linking it by itself into a dynamic library (-nostdlib) will get a library with an executable data segment. Now on to figure out why.
It uses a REL32 relocation to refer to _GLOBAL_OFFSET_TABLE_, which gets htab->old_plt set, so we use the old layout that requires executable permission on the GOT and the PLT. It gets more confusing because simplifying that input file to an empty function still caused the old GOT and PLT layouts to be selected by default. I suppose it's related with the use of TLS, let's see...
Created attachment 125909 [details] GCC patch that fixes the problem It was the TLS sequences, after all. The code used to compute the address of _GLOBAL_OFFSET_TABLE_ was regarded by the linker as requiring the old GOT/PLT layout. Many thanks to RTH for, erhm, being dragged into the problem when I had to go pick up my daughter at school, and for coming up with the final spelling of the patch.
Created attachment 125914 [details] Patch that fixes the problem correctly :-) As it turned out, GCC failed to build libmudflap with the previous patch :-( Here's an even more conservative patch, that will use an additional dynamic relocation in the TOC to compute the _GLOBAL_OFFSET_TABLE_ address. prelink should render that additional dynamic relocation a no-op, and we generate smaller and faster code, so it's an overall win, except for non-prelinked binaries, that take this small startup-time penalty.
For the record, the following packages/libraries in Core need rebuilding after the GCC build is complete: lftp-3.4.2-4.ppc.rpm ./usr/lib/lftp/3.4.2/cmd-mirror.so lftp-3.4.2-4.ppc.rpm ./usr/lib/lftp/3.4.2/cmd-sleep.so lftp-3.4.2-4.ppc.rpm ./usr/lib/lftp/3.4.2/liblftp-network.so lftp-3.4.2-4.ppc.rpm ./usr/lib/lftp/3.4.2/liblftp-pty.so lftp-3.4.2-4.ppc.rpm ./usr/lib/lftp/3.4.2/proto-file.so lftp-3.4.2-4.ppc.rpm ./usr/lib/liblftp-jobs.so.0.0.0 lftp-3.4.2-4.ppc.rpm ./usr/lib/liblftp-tasks.so.0.0.0 libgcj-4.1.0-2.ppc.rpm ./usr/lib/libgcj.so.7.0.0 libmudflap-4.1.0-2.ppc.rpm ./usr/lib/libmudflapth.so.0.0.0 libstdc++-4.1.0-2.ppc.rpm ./usr/lib/libstdc++.so.6.0.8 libstdc++so7-4.2.0-0.3.20060203.1.ppc.rpm ./usr/lib/libstdc++-20060203.so.7.0.0 libwvstreams-4.2.1-1.2.ppc.rpm ./usr/lib/libwvbase.so.4.2 mono-core-1.1.13.4-1.ppc.rpm ./usr/lib/libmono.so.0.0.0 numactl-0.6.4-1.26.2.ppc.rpm ./usr/lib/libnuma.so.1 openoffice.org-core-2.0.2-5.1.2.ppc.rpm ./usr/lib/openoffice.org2.0/program/libstore.so.3 Testing the new patch revealed that, if you take an object file compiled with -fPIC that accesses locally-defined thread-local variables, and link that into a main executable, the linker will relax the dynamic access models incorrectly. This is true with the code we generated after the patch, but it was already true with the code we generated before, so I take it that this other error is not a blocker. I'll clone that into a separate bug and then try to address it as well. This linker failure does not affect in any way the fix that goes into GCC, since the GCC failure was only observed in dynamic libraries, and the linker failure only affects main executables (it's the local exec access model that breaks). It might turn out that it is not a linker problem, but rather a glibc problem, if the segmentation fault is not because the relaxed code computes the wrong address for the variable, but rather that say glibc fails to map the portion of the stack reserved for the Static TLS block as readable or something like that. Very unlikely, but I thought I'd point out the possibility, just to test how long people can hold their breaths ;-)
Created attachment 126265 [details] Patch that fixes the bug in the linker As it turned out, Alan Modra decided the linker was in error for considering the code sequence emitted by GCC as a request for old GOT, so we should revert the GCC change and update binutils with this patch, arranging for the GCC update to require this updated binutils, at least on ppc.
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
Final Freeze is in effect now. Security fixes almost certainly warrant a freeze break, so in case you build a fix for this, mail release engineering as described here: [2] [1] https://www.redhat.com/archives/fedora-devel-announce/2008-April/msg00007.html [2] http://fedoraproject.org/wiki/ReleaseEngineering/FinalFreezePolicy Thanks!
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Hrm, this is a very old bug, was it ever fixed for 9, or still present in 10?
I have not heard about it again, I will close it for now and see if it comes back.