Red Hat Bugzilla – Bug 438308
changes in rhel5.2 gcc caused gdb.base/prelink.exp to FAIL
Last modified: 2016-09-19 22:04:01 EDT
Description of problem:
When testing tools errata for RHEL5.2, I discovered that after updating to
candidate gcc (gcc-4.1.2-41.el5), gdb's internal testsuite test gdb.base/
prelink.exp started to FAIL (PASS previously). This occurs with both rhel5.1
and rhel5.2 candidate gdb (gdb-6.5-25.el5_1.1 and gdb-6.5-37.el5), so the
changes in gcc seem to be the causing factor.
The test is trying to guess if the different address of .dynamic section is
caused by prelink.
Version-Release number of selected component (if applicable):
gdb-6.5-25.el5_1.1 and gdb-6.5-37.el5
always (at least for i386)
Steps to Reproduce:
1. install gdb-6.5-37.el5 src.rpm and apply gcc erratum (4.1.2-41.el5)
2. cd /usr/src/redhat/BUILD/gdb-6.5/gdb/testsuite
3. runtest --tool=gdb gdb.base/prelink.exp
Test fails. GDB doesn't emit this warning which is expected by testcase:
warning: .dynamic section for "/usr/src/redhat/BUILD/gdb-6.5/gdb/testsuite/
gdb.base/prelink.so" is not at the expected address
warning: difference appears to be caused by prelink, adjusting expectations
I know that this could be a bug in gdb (or even the testcase) as well, but the
changes were introduced in gcc so I filed it for gcc. I don't know if this is
present on other arches, I have relevant results only for i386 and ia64 where
prelink is not present.
Created attachment 298681 [details]
test log with
Created attachment 298682 [details]
testcase log for
sorry, comment 1 should state gcc-4.1.2-14.el5, not -41
# runtest gdb.base/prelink.exp
Running ../../../gdb/testsuite/gdb.base/prelink.exp ...
prelink: Could not set security context for
does not have .gnu.prelink_undo section
`setenforce 0' "fixes" this problem.
But it behaves randomly/unreproducively. Not sure if it is related to whether
auditd is running - IMO I also fixed the problem by `service auditd start'.
Reproducer (but in some machine mood it works):
# touch empty.c; gcc -o empty.so -shared -fPIC -Wall empty.c; prelink -qNR
prelink: Could not set security context for /root/jkratoch/redhat/empty.so:
"security.selinux"..., "root:object_r:user_home_t:s0", 29, 0) = -1 EACCES
write(2, "prelink: ", 9) = 9
write(2, "Could not set security context f"..., 65) = 65
No selinux messages in the system log found.
Fixed in /selinux-policy-2.4.6-126.el5.src.rpm
ad comment 4: that is IMO different issue. My tests were run with permissive
mode and the only difference between PASS and FAIL is the version of gcc as
stated on comment 0
For the selinux part:
(In reply to comment #5)
> Fixed in /selinux-policy-2.4.6-126.el5.src.rpm
I do not see a %changelog entry for it but the files changed there for prelink:
* Tue Mar 11 2008 Dan Walsh <email@example.com> 2.4.6-126
- Allow lvm to create fifo_file
- Fix building of policy modules with Makefile
And I can confirm it no longer fails during my attempt (although it was not
always reproducible even before).
Created attachment 298807 [details]
GDB testcase fix.
For the GDB part:
It is only a testcase problem, no need for a RHEL-5.2 GDB respin.
Explanation to be possibly approved by Jakub:
`--no-exec-shield' is for i386 where prelink in the exec-shield mode is
forced to push all the libraries tight together to fit into the first two
memory areas (either the ASCII Shield area or at least below the executable).
In this case its -R option cannot be applied and we falsely FAIL here as if
the system is already prelinked prelink has no choice how to randomize the
single new unprelinked library address without wasting the first one/two
memory areas. We do not care of the efficiency of loading such resulting
exec-shield unfriendly prelinked library.
THe change was to make prelink and unconfined app, Since it can currently
rewrite every executable on the system, having it confined makes no sense. It
has been unconfined in F7, F8, F9
Plus people expect prelink to be able to read every directory on the system
since they could put an executable anywhere.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.