+++ This bug was initially created as a clone of Bug #165416 +++

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.

-- Additional comment from roland@redhat.com on 2005-08-09 01:43 EST --
Created an attachment (id=117565)
patch to change %__os_install_post macro


-- Additional comment from fche@redhat.com on 2005-08-09 12:30 EST --
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.


-- Additional comment from roland@redhat.com on 2005-08-10 03:58 EST --
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.  

-- Additional comment from fche@redhat.com on 2005-08-10 10:58 EST --
Confirming that workaround works around.

-- Additional comment from roland@redhat.com on 2005-08-15 17:16 EST --
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.

-- Additional comment from sopwith@redhat.com on 2005-08-16 20:39 EST --
Should be fixed in CVS