[Bug translator/10678] vta-gcc: cannot find module nfs debuginfo: relocation refers to undefined symbol

["roland at gnu dot org" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From roland at gnu dot org  2009-09-22 00:15 -------
Ok, the case here is something that never came up before: the DWARF for an entry
in nfs.ko really does require relocation against a symbol defined in another
module.  This happens because there is a DW_AT_const_value on a variable that
has the compile-time constant value of &kmalloc_caches[10].  This is a proper
constant and it's the right thing for the compiler to produce.  In general, this
could happen in any module depending on another (not just depending on vmlinux).

In the medium term, this will be mitigated implicitly by the future libdw
behavior that won't care about this reloc until you want to evaluate that
DW_AT_const_value (or equivalent situation).  With that and nothing else, the
impact will be limited to the particular $foo being unresolvable when requested.

In the short term, it is pretty likely that this is only coming up with
references from foo.ko to vmlinux.  You can find all the other affected
.ko.debug's on hand easily by running tests/dwflmodtest -e foo.ko.debug on them
each and looking for the relocation error.  In all likelihood, -e vmlinux -e
foo.ko.debug will make that work on each of those.  If so, then it is an
adequate workaround for now to have stap just always include the "kernel" module
in the set admitted by its predicate.

In the long term/general case, you may have to figure out what other module is
required and go add it to the Dwfl.  In the medium term scenario, you could do
this lazily upon getting a "DWARF data requires relocation" error (and we can
make those give you the symbol details to make it easy)--or even possibly just
resolve those to a load-time intermodule reference in the generated module
(though that is trickier for a stap module loaded before its probee modules). 
In the short term scenario (i.e. current elfutils), you could do that
preemptively.  Whenever you want to do that, you can do it fairly easily by
using the modules.dep data.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10678

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.