Bug 165416
| Summary: | running binutils strip -g after elfutils eu-strip -f considered harmful | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Roland McGrath <roland> | ||||
| Component: | redhat-rpm-config | Assignee: | Elliot Lee <sopwith> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | rawhide | CC: | fche | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2005-08-17 00:39:41 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | 165528 | ||||||
| Bug Blocks: | 189116, 189118, 189148 | ||||||
| Attachments: |
|
||||||
Created attachment 117565 [details]
patch to change %__os_install_post macro
Test results on fc3 2.6.12-1.1371_FC3smp kernel, elfutils 0.111-1, and above patch indicate that the new kernel boots, and the modules' debuginfo is now parseable by systemtap/elfutils. However, the resulting modules *do not load* into the kernel. insmod fails, and leaves "Verify ELF error (assertion 110) / Module failed ELF checks" in ksyslog. Booting the original kernel, and attempting to load the new .ko's results in the same error message. See bug 165528. You can in fact work around the problem by appending garbage bytes to the .ko files, i.e. echo >> /lib/modules/.../foo.ko, and then the kernel will take it fine. Confirming that workaround works around. The kernel bug #165528 that led to unusable kernel builds has been fixed in devel cvs. So the attached fix to the macros can safely go into buildroots now. Elliot, please put it in or respond if the patch is wrong somehow. Should be fixed in CVS |
Description of problem: /usr/lib/rpm/redhat/brp-strip gets run after /usr/lib/rpm/find-debuginfo.sh. The latter uses eu-strip -f foo.debug foo (elfutils strip), and the former then uses strip -g foo (binutils strip). The binutils strip modifies the symbol tables in stripped ET_REL files (such as kernel .ko files), so that the separate debuginfo files (.ko.debug) no longer jibe with the symbol tables in the main rpm's stripped files. Version-Release number of selected component (if applicable): 8.0.38-1, and all prior since we have used eu-strip for -debuginfo rpms. How reproducible: 100% Steps to Reproduce: 1. Build an rpm that installs ET_REL objects, like kernel .ko files. 2. Look at the kernel-debuginfo (or whatever-debuginfo) rpm you get. 3. See .rel.debug_info relocs in .ko.debug files referring to symbols that make no sense given the main rpm's stripped .ko files' symbol tables. Actual results: Symbol tables in stripped files have been diddled since debuginfo separation. Expected results: No diddling. Additional info: Using eu-strip -g on stripped output from eu-strip doesn't actually hurt. So one approach would be to set %{__strip} to eu-strip instead of binutils strip. I don't think we should do that generically in /usr/lib/rpm/macros until we are ready to just replace binutils strip with eu-strip, and then we can just make it /usr/bin/strip and leave the macro alone. Whether the problematic binutils strip or the currently harmless eu-strip, I think it is best to say that if you use some symbol table modification program like strip on the output of eu-strip -f, then all bets are off for making sense of the separate debuginfo file with respect to the modified version of its twin. Instead I propose the attached patch, which disables the redundant brp-strip step completely when find-debuginfo.sh is being used. (I have not actually tested this patch yet.) This change needs to be done for all release streams where we produce kernel-debuginfo rpms. But I will hold off on cloning the bug out the wazoo until it gets some feedback.