Description of problem: elfutils 0.123 (and many earlier versions) don't pass testsuite on alpha platform. How reproducible: Build elfutils, cd to "tests" directory and invoke "make check". Additional info: I made a patch which updates alpha platform support so that testsuite is passed: http://cvs.pld-linux.org/SOURCES/elfutils-alpha.patch?rev=1.6
Created attachment 134974 [details] Update alpha platform support (for elfutils 0.123) I'm attaching patch mentioned above.
Comment on attachment 134974 [details] Update alpha platform support (for elfutils 0.123) Patch updated for elfutils 0.124
Created attachment 141495 [details] Update alpha platform support (for elfutils 0.124) Aah. I hope this way updated patch would be attached.
Created attachment 150275 [details] Update alpha platform support (for elfutils 0.126)
I think I have the alpha bits right upstream now.
I believe alpha support is happy in 0.128 (on its way to rawhide, already in fedora cvs). Please verify.
These issues are gone. But there is one new: loadable segment GNU_RELRO applies to is executable *** failure in ../libelf/libelf.so FAIL: run-elflint-self.sh (the same on sparc as I've been told)
That is probably finding an ld bug (binutils). Can you show me the eu-readelf -Sl output on an object that elflint rejects?
Created attachment 196521 [details] Partial `eu-readelf -a addr2line` output on alpha
Created attachment 196531 [details] `eu-readelf -Sl libelf.so` output on alpha
Created attachment 196541 [details] `eu-readelf -Sl libelf.so` output on sparc
Created attachment 196551 [details] `eu-readelf -Sl libelf.so` output on sparc64
Here are requested information dumps (from alpha, sparc and sparc64, on which elflint-self test fails on libelf.so). I also included a part of `eu-readelf -a addr2line` dump from alpha, as I got a new elflint-self failure (on elfutils 0.129): section [36] '.symtab': symbol 69: st_value out of bounds section [36] '.symtab': symbol 88: st_value out of bounds *** failure in ../src/addr2line This might be related to binutils version... if it matters, I have binutils-2.17.50.0.16 on alpha and binutils-2.17.50.0.8 on sparc.
The elflint complaints look valid and the details in those objects are indeed wrong. You have one or more ld bugs here, and AFAICT no elfutils bugs. The data segment is executable, which is not right unless Alpha's .plt is real funny. If the data should be executable, RELRO should not apply to that segment, I think. That one might be questionable. The st_value complaints are valid, the data_start and __data_start symbols in that output are outside the section they claim to be in. Another suspect thing is the LOOS+84153728 phdrs, which look totally bogus (that is not a valid p_type I know of, 0x65041580).
*** Bug 318371 has been marked as a duplicate of this bug. ***
elfutils-0.128 works just fine here: elfutils-0.128-2.fc7 binutils-2.17.50.0.18-1 gcc-4.1.2-29 I attached the full and correct buildlog from my elfutils-0.129 to Bug #318371. I'll attach [oliver@gosa elfutils]$ eu-readelf -Sl ./elfutils-0.129/libelf/libelf.so > output now; My output is different maybe it helps.
Created attachment 217161 [details] eu-readelf -Sl ./elfutils-0.129/libelf/libelf.so output
The only issue remaining is the RELRO segment. So far this appears to be a correct diagnosis by elflint, and how it's produced is a bug in ld (binutils). The same issue occurs on sparc.
Roland, you think we should reassign this to binutils? I think Jakub will then be the owner - isn't it? Or shall we just take binutils maintainer CC:? The strange thing to me is, that I cannot even recompile the old elfutils. I start to think this has something to do with the new --hash-style option!?
This report has already been overloaded talking about a few different problems, all of which have been fixed in elfutils. It is time to close it. The RELRO complaint is not an elfutils bug. The DSO layout under -z relro may well be an ld bug. File a bug for binutils about that. Whatever compilation issues you are having are yet a third issue, and probably not something for a Fedora bugzilla report at all.
OK Roland. Will bug other place then :-)
Roland, the binutils bug should be fixed now, with the patch mentioned here: http://sourceware.org/bugzilla/show_bug.cgi?id=5149 But elfutils still spots that error :-(
Can you attach the new eu-readelf -Sl output?
Created attachment 235321 [details] eu-readelf on libelf/libelf.so with patched binutils to fix GNU_RELRO Sure. Output attached.
H.J. Lu thinks that there now is a bug in elflint; I have already created a link to sourceware, so you can easily check...
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.
This bug is still true for f8, f9/rawhide. I see sparc listed in the no test section of elfutils. Maybe we should do this with alpha as well, as it doesn't seem to *break* anything atm.
Things are just all fixed for sparc as of the next release (0.134). I'd rather see things get fixed for alpha.
Where can I get a copy of 0.134 alpha, beta, rc0 rc1, whatever ? :-)
0.134 still generates the same error: <snip> PASS: run-elflint-test.sh section [38] '.symtab': symbol 66: st_value out of bounds section [38] '.symtab': symbol 85: st_value out of bounds *** failure in ../src/addr2line FAIL: run-elflint-self.sh <snip> </snap> ===================================================== 1 of 66 tests failed Please report to http://bugzilla.redhat.com/bugzilla/ ===================================================== make[3]: *** [check-TESTS] Error 1 make[2]: *** [check-am] Error 2 make[1]: *** [check-recursive] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.70371 (%check) </snap>
That is not the error we were talking about. The st_value complaints are valid diagnosis of an ld (binutils) bug, AFAIK.
So. What are the further steps. Disable testing on alpha or is anybody able to fix the problem. AFAICS, it doesn't make problems if you disable testing and use elfutils...
Attach eu-readelf -a output along with the eu-elflint errors from any object still failing. Then we can verify if the "out of bounds" error is a correct diagnosis of an ld bug.
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
elfutils-0.135-1.fc7 has been submitted as an update for Fedora 7
elfutils-0.135-1.fc8 has been submitted as an update for Fedora 8
elfutils-0.135-1.fc9 has been submitted as an update for Fedora 9
elfutils-0.135-1.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update elfutils'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F7/FEDORA-2008-4457
elfutils-0.135-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
elfutils-0.135-1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
Created attachment 313674 [details] elflint on addr2line
Created attachment 313675 [details] readelf -a on addr2line
Seems to get worse :-(
Running from your build tree requires LD_LIBRARY_PATH=libelf:libdw:backends. Please show the elflint output when it gets the right backend library.
Also note the run-elflint-self.sh test passes --gnu-ld to elflint.
Already guess something must be wrong. :-( Sorry. [oliver@kriek elfutils-0.135]$ LD_LIBRARY_PATH=libelf:libdw:backends src/elflint --gnu-ld src/addr2line section [37] '.symtab': symbol 65: st_value out of bounds section [37] '.symtab': symbol 84: st_value out of bounds The readelf output should be fine, right?
The situation is the same as before. Those two errors are about data_start and __data_start, which are two symbols with the same value/section (aliases defined together). It looks like there is an ld bug here. The st_value of data_start is not plausible. It's supposed to be the beginning of .data, but there is no .data section at all. If there were, I'm sure it would have st_align=8, so that would not be its address. Somehow these symbols have ended up pointing to the .got section but with an address that's 4 bytes before .got (and thus misaligned).
Roland. Fine, it seems an ld bug, I don't even want to think about what an ld bug on alpha platform might imply... :-( However. I don't have any 'good contacts' to binutils guys. So do you have? fyi. The binutils version I used for this test: 2.18.50.0.8 (rawhide rpm).
Just post to bug-binutils about the problem. You can CC me and I'll be happy to explain the details I've seen further. What I've already told you should be clear to ld hackers. As to finding one who wants to fix alpha, good luck.
(In reply to comment #49) > Just post to bug-binutils about the problem. You can CC me and I'll be happy > to explain the details I've seen further. What I've already told you should be > clear to ld hackers. As to finding one who wants to fix alpha, good luck. Sent a mail to the list, but no reaction yet.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
These bugs are fixed in current Fedora 10/11 updates of elfutils.