Bug 2149223

Summary: unhandled DW_OP operation in DWARF expression
Product: Red Hat Enterprise Linux 9 Reporter: Martin Cermak <mcermak>
Component: systemtapAssignee: Frank Ch. Eigler <fche>
systemtap sub component: system-version QA Contact: Martin Cermak <mcermak>
Status: CLOSED ERRATA Docs Contact:
Severity: unspecified    
Priority: unspecified CC: lberk, mcermak, mjw, wcohen
Version: 9.2Keywords: Triaged
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: systemtap-4.8-2.el9 Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of:
: 2156093 (view as bug list) Environment:
Last Closed: 2023-05-09 07:37:36 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2144442, 2156093    

Description Martin Cermak 2022-11-29 09:08:32 UTC
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 #

Comment 1 Mark Wielaard 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)

Comment 2 Mark Wielaard 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)

Comment 3 Martin Cermak 2022-11-29 11:35:19 UTC
Which is already known bz1997192.  Thanks! :)

Comment 4 Mark Wielaard 2022-11-29 17:52:56 UTC
Proposed upstream patch:
https://inbox.sourceware.org/systemtap/20221129175058.32728-1-mark@klomp.org/

Comment 7 errata-xmlrpc 2023-05-09 07:37:36 UTC
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