Red Hat Bugzilla – Bug 184446
libstdc++ requires execmem priviledge on ppc platform
Last modified: 2013-01-09 22:41:33 EST
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
[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
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:
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:
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: 
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
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.