https://bugzilla.suse.com/show_bug.cgi?id=1196060 https://bugzilla.suse.com/show_bug.cgi?id=1196060#c8 Richard Biener <rguenther@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mliska@suse.cz --- Comment #8 from Richard Biener <rguenther@suse.com> --- (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)? There might be changes in the debug info that systemtap does not recognize, I'm not sure if the above diagnostics are a sign of that - somebody more familiar with systemtap should see what 'semantic error: resolution failed in DWARF builder' actually means. It could be it just fails to lookup a symbol, but maybe it's more. There's both the compiler and eventually dwz coming into play - to rule out the latter can you try disabling dwz? (I think you can do #!BuildIgnore: dwz when building the kernel and modules) You can also try if it's some new DWARF5 that confuses sytemtap by forcing GCC to use DWARF4 - you somehow need to inject -gdwarf-4 into the kernel/modules build to test that. Eventually it's also elfutils (CCing maintainer) which systemtap seems to use for DWARF parsing (libdw, that is). -- You are receiving this mail because: You are the assignee for the bug.