Comment # 9 on bug 1196060 from Tony Jones

(In reply to Richard Biener from comment #8)
> (In reply to Tony Jones from comment #5)
> > ok.  definitely a regression here vs SP3.  I'll look at it.
> > 
> > # stap -vv --poison-cache -l 'module("ext4").function("*")'
> > ...
> > derive-probes (location #0): module("ext4").function("*") of keyword at
> > <input>:1:1
> > semantic error: resolution failed in DWARF builder
> >    thrown from: elaborate.cxx:1093
> > semantic error: resolution failed in DWARF builder
> >    thrown from: elaborate.cxx:1093
> > semantic error: while resolving probe point: identifier 'module' at
> > <input>:1:7
> >    thrown from: elaborate.cxx:1081
> >         source: probe module("ext4").function("*") {}
> >                       ^
> > 
> > semantic error: no match
> >    thrown from: elaborate.cxx:1044
> 
> Is this with the same kernel/module .ko or comparing results with different
> .kos (from SP3 and Tumbleweed)?

Same OS in all cases.  Also SP3 works fine.

> Eventually it's also elfutils (CCing maintainer) which systemtap seems to
> use for DWARF parsing (libdw, that is).

Sorry I thought you were the libdw maintainer.

The problem appears to be debugging a kernel module ("module.function") in
systemtap syntax when the main .ko for the module has been stripped and the
debugging info is in a separate debuginfo.

- systemtap is not having an issue debugging the primary kernel (aka
"kernel.function works fine").

- systemtap is not having an issue debugging modules for a hand built kernel
(here "module.function" works).

So I don't think it's a DWARF5 vs DWARF4 issue.  I don't think dwz is an issue
(though I am curious why there is no support for it in elfutils). 

As I said in previous comment, the debuginfo version of the ext4.ko is where
the debug info resides yet is not being referenced at all (per strace log).

I'll look more at systemtap today.  The ability to debug what is going on at
this level isn't great.