From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BE2BB3858425; Wed, 5 Jan 2022 22:02:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BE2BB3858425 From: "raeburn at redhat dot com" To: systemtap@sourceware.org Subject: [Bug bpf/28748] New: systemtap bpf unsupported functions and other failures Date: Wed, 05 Jan 2022 22:02:12 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: systemtap X-Bugzilla-Component: bpf X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: raeburn at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: systemtap at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: systemtap@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Systemtap mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2022 22:02:12 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28748 Bug ID: 28748 Summary: systemtap bpf unsupported functions and other failures Product: systemtap Version: unspecified Status: NEW Severity: normal Priority: P2 Component: bpf Assignee: systemtap at sourceware dot org Reporter: raeburn at redhat dot com Target Milestone: --- Bugzilla only offers me =E2=80=9Cunspecified=E2=80=9D for a version; I=E2= =80=99m working with: Systemtap translator/driver (version 4.6/0.186, rpm 4.6-4.fc35) Copyright (C) 2005-2021 Red Hat, Inc. and others This is free software; see the source for copying conditions. tested kernel versions: 2.6.32 ... 5.15.0-rc7 enabled features: AVAHI BOOST_STRING_REF DYNINST BPF JAVA PYTHON3 LIBRPM LIBSQLITE3 LIBVIRT LIBXML2 NLS NSS READLINE MONITOR_LIBS on a Fedora 5.15.7-200.fc35.x86_64 kernel. I was trying a script with kernel-module probes which, first, were failing = to find the variable I wanted to examine at the lines I wanted, right after a function returns, so I tried probes on the function (saving the pointer pas= sed) and the corresponding .return probe (fetch the value at the saved location = and print it out), but the .return probe never fired. (I see this issue has com= e up on the mailing list around the same time I was running into it This is an out-of-kernel module, built using standard kernel makefile suppl= ied options. The function call was between object files but LTO might be enable= d. After a bit of frustration, I decided to try the BPF back end and see if I = got any different results. (For all I know, perhaps the probe point determinati= on and local variable locating code are common, and the experiment could be a waste of time. But I don=E2=80=99t know, so I decided to try it out.) Unfortunately (but perhaps not surprisingly, it still being in early stages= of development), the results were worse: * deleting an array isn=E2=80=99t supported * kernel_long() and kernel_pointer() aren=E2=80=99t recognized (=E2=80=9Cu= nresolved function=E2=80=9D) * tid() isn=E2=80=99t supported (=E2=80=9Cbpfinterp.cxx:1127: unknown help= er function=E2=80=9D) * =E2=80=9CError creating probe 0: Invalid or incomplete multibyte or wide= character=E2=80=9D though all my own strings seem to be ASCII as far as I can see This last one is coming from a fairly stripped down input file: probe module("uds").function("wait_for_pending_searches") { printf("%d: wfps\n", tid()); } The function being probed is a static function static void wait_for_pending_searches(struct page_cache *cache, unsigned int physical_page) =E2=80= =A6 which is called from two places in its source file. If I strip it down further =E2=80=94 just a =E2=80=9Cbegin=E2=80=9D probe, = printing its own thread id =E2=80=94 that=E2=80=99s when I get the =E2=80=9Cunknown helper function=E2=80=9D. Lo= oking at bpfinterp.cxx, it appears that BPF_FUNC_get_current_pid_tgid is supplied somewhere (hardcoded= in tapset/bpf/context.stp?) but not implemented in the interpreter. Looking at other =E2=80=9Ccall BPF_FUNC_=E2=80=A6=E2=80=9D lines in tapset/= bpf and comparing against stapbpf/bpfinterp.cxx, I=E2=80=99d hazard a guess that uses of BPF_FUNC_get_current_uid_gid, BPF_FUNC_get_smp_processor_id, and BPF_FUNC_gtod_get_ns might also hit problems. And calls to gid(), uid(), and cpu() all generate the same error. Calling gettimeofday_ns() seems to be ok= ay though=E2=80=A6 The last point took me a while to figure out, actually, as printf("%d",=E2= =80=A6) works just fine normally for =E2=80=9Clong=E2=80=9D values, but in BPF mode I see= m to need the %ld format or the value gets truncated to 32 bits. No warning is given about the truncation, though all the necessary type info should be available. So=E2=80=A6 is there a list somewhere of what is or is not expected to work= with the BPF back end? I see the stapbpf man page and its list of probes and some ot= her general info, but it=E2=80=99s not very detailed. --=20 You are receiving this mail because: You are the assignee for the bug.=