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)

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)

Which is already known bz1997192.  Thanks! :)

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

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (systemtap bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:2241