Bug 1966 - rebuilt .ko debuginfo suspect - relocation symbol errors
Summary: rebuilt .ko debuginfo suspect - relocation symbol errors
Status: RESOLVED INVALID
Alias: None
Product: systemtap
Classification: Unclassified
Component: tapsets (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-02 03:12 UTC by Li Guanglei
Modified: 2011-03-16 21:19 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Li Guanglei 2005-12-02 03:12:17 UTC
Today I tried to add probe points to some functions in modules, ex:

probe module("scsi_mod").function("scsi_dispatch_cmd")
{
   log("here")
}

but stap will give the error:

root:/root>stap a.stp
WARNING: cannot find module scsi_mod debuginfo: relocation refers to undefined
symbol
semantic error: no match for probe point
     while: resolving probe point module("scsi_mod").function("scsi_dispatch_cmd")
Pass 2: analysis failed.  Try again with '-v' (verbose) option.

And I got the same kind of error when I probed module("ext3").function("*")

But when I tried to probe module("sd_mod").function("*"), it succeed.

After looked into the systemTap src, I found this error was generated by calling
__libdwfl_relocate:

Breakpoint 4, load_dw (mod=0x9aeff90, debugfile=0x9aeffc4) at
dwfl_module_getdwarf.c:306
306     result = __libdwfl_relocate (mod, debugfile->elf);
(gdb) p result
$72 = DWFL_E_RELUNDEF
(gdb) p *debugfile
$73 = {name = 0x9af17b8 
"/usr/lib/debug/lib/modules/2.6.9-22.17.EL.root/kernel/drivers/scsi/scsi_mod.ko.debug",
fd = 8, elf = 0x9af1820, bias = 0}

The environment of my systems: 2.6.9-22.17.EL, elfutils-xxx-0.116-0.1, gcc
3.4.4, ppc64 and i386

I am not sure if it's a bug of elfutils or a bug of systemTap.
Comment 1 Frank Ch. Eigler 2005-12-02 13:51:10 UTC
Roland, could you look into why kernels built with new elfutils / gcc seem to
have this module relocation problem?
Comment 2 Frank Ch. Eigler 2005-12-02 13:59:39 UTC
By the way, please note that installing elfutils 0.116, replacing the system RPM
on an RHEL machine is not actually supported.  The RHEL systemtap RPM includes
an embedded elfutils package, and leaves the system RPM alone.

Would you mind trying to install back the proper RHEL elfutils for the duration
of the kernel compile?
Comment 3 Roland McGrath 2005-12-02 21:59:46 UTC
See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165416 for the details.
The issue is using rpmbuild to make debuginfo rpms when elfutils eu-strip is
installed.  This is not a problem for RH builds of RHEL4 kernel rpms because the
elfutils eu-strip is not actually used and the rpmbuild bug of running strip a
second time does not hurd when the eu-strip used to create the .debug files was
from binutils.  Hence it has not been a priority to fix RHEL4's rpmbuild to
avoid that problem, since RH does not support rebuilding ones own kernel rpms on
RHEL4 anyway.  It is straightforward to tweak one's system to put the fix in by
hand, or (probably more adviseable) to hack your .spec file to circumvent the
problem.
Probably the shortest hack you can put in is:

%define __strip /usr/bin/eu-strip

and I think that will do it (though it differs from the fix applied to the
system specs in Fedora).

There is no problem with systemtap or elfutils here, just a botch in building
your own kernels using the rpm tools.