Bug 2156093

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

There seems to be an unhandled DW_OP operation in DWARF expression on rhel9 aarch64 and ppc64le.  The .debug file should be avail in brew.  I assume this is an elfutils problem, please, reassign if I'm wrong:

9 aarch64 # stap -vvvvp4 -e 'probe nfs.proc.commit_done { log(server_ip) }' |& fgrep -A9 'unhandled DW_OP operation' | head -9
semantic error: unhandled DW_OP operation in DWARF expression [0] at 0 (163: 1, 281472520729107)
        dieoffset: 0x642a4 from /usr/lib/debug/usr/lib/modules/5.14.0-197.el9.aarch64/kernel/fs/nfs/nfsv3.ko.debug
   thrown from: loc2stap.cxx:719

finding location for local 'task' near address 0x1084c, module bias 0
get_cfa_ops @0x1084c, module_start @0x10000
got dwarf cfi bias: 0x0
found cfa, info: 30 [start: 0x10838, end: 0x10860, nops: 1
chaining to identifier '$task' at /usr/share/systemtap/tapset/linux/nfs_proc.stp:1446:26
9 aarch64 #
9 aarch64 #
9 aarch64 #
9 aarch64 # rpm -q systemtap elfutils
systemtap-4.8-1.el9.aarch64
elfutils-0.188-3.el9.aarch64
9 aarch64 #

--- Additional comment from Mark Wielaard on 2022-11-29 11:13:18 UTC ---

Found it on a ppc64le rhel9 setup:

# stap -vvvvp4 -e 'probe nfs.proc.commit_done { log(server_ip) }' |& grep -A9 'unhandled DW_OP operation' | head -9
semantic error: unhandled DW_OP operation in DWARF expression [0] at 0 (163: 1, 140735826504875)
        dieoffset: 0x67bdd from /usr/lib/debug/usr/lib/modules/5.14.0-197.el9.ppc64le/kernel/fs/nfs/nfsv3.ko.debug
   thrown from: loc2stap.cxx:719

finding location for local 'task' near address 0x10d88, module bias 0
get_cfa_ops @0x10d88, module_start @0x10000
got dwarf cfi bias: 0x0
found cfa, info: 65 [start: 0x10d74, end: 0x10da0, nops: 1
chaining to identifier '$task' at /usr/share/systemtap/tapset/linux/nfs_proc.stp:1446:26

So this happens at dieoffset: 0x67bdd from /usr/lib/debug/usr/lib/modules/5.14.0-197.el9.ppc64le/kernel/fs/nfs/nfsv3.ko.debug for the 'task' variable.

Looking for the DIE at 67bdd with eu-readelf --debug-dump=info /usr/lib/debug/usr/lib/modules/5.14.0-197.el9.ppc64le/kernel/fs/nfs/nfsv3.ko.debug we find:

 [ 67bdd]        formal_parameter     abbrev: 10
                 abstract_origin      (ref4) [ 6151a]
                 location             (sec_offset) location list [  3443]
                 GNU_locviews         (sec_offset) location list [  3441]

So the location is described at offset 3343. Which we can lookup with eu-readelf --debug-dump=loc /usr/lib/debug/usr/lib/modules/5.14.0-197.el9.ppc64le/kernel/fs/nfs/nfsv3.ko.debug

  Offset: 3443, Index: 31d1
    offset_pair 9d8, 9e8
      .text+0x0000000000000d18 <nfs3_commit_done+0x70>..
      .text+0x0000000000000d27 <nfs3_commit_done+0x7f>
        [ 0] entry_value:
             [ 0] reg3
        [ 3] stack_value
    end_of_list

So the unhandled op is DW_OP_entry_value.

This is the DWARF5 variant of the DWARF4 GNU extension of DW_OP_GNU_entry_value.

Looking at stap2loc.c we find we only try to handle the GNU variant, so maybe a (totally untested) fix might be:

diff --git a/loc2stap.cxx b/loc2stap.cxx
index efc78cc57..bcd574943 100644
--- a/loc2stap.cxx
+++ b/loc2stap.cxx
@@ -684,6 +684,7 @@ location_context::translate (const Dwarf_Op *expr, const size_t len,
            break;
 
          case DW_OP_GNU_entry_value:
+         case DW_OP_entry_value:
            {
              expression *result = handle_GNU_entry_value (expr[i]);
              if (result == NULL)

--- Additional comment from Mark Wielaard on 2022-11-29 11:23:17 UTC ---

Quick test with the above "fix" shows it changes the error to:

semantic error: invalid access '->task' vs 'void*': operator '->' at :16:21
   thrown from: dwflpp.cxx:3576
        source:         ( get_ip(&@nfs_data->task) )
                                           ^
        in expansion of macro: operator '@_nfs_data_server_ip' at /root/systemtap/tapset/linux/nfs_proc.
stp:1445:15
        source:                 server_ip = @_nfs_data_server_ip($task->tk_calldata)

--- Additional comment from Martin Cermak on 2022-11-29 11:35:19 UTC ---

Which is already known bz1997192.  Thanks! :)

--- Additional comment from Mark Wielaard on 2022-11-29 17:52:56 UTC ---

Proposed upstream patch:
https://inbox.sourceware.org/systemtap/20221129175058.32728-1-mark@klomp.org/