From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 14FDE3858D38; Mon, 7 Nov 2022 10:35:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 14FDE3858D38 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1667817338; bh=mnDl4N0EluKN6CghB32oDAQ0JGxojc/6JXmyMSU1opQ=; h=From:To:Subject:Date:From; b=ZN2CojJiR8WE0f2FRpdHjHOwm2Fst9pnG7ExM8sted4t2yyU8WsomVrwBmLebRMZ/ p2ozT8BxAtW5BTeb8qITo8EXupCUsSarK8923VVeBIIDgBLheei32DQ7UbNjAj/xaK HKOV7/h3SiDBkSXWmnyzd9dNc4BtySbu5aVfDnMY= From: "mcermak at redhat dot com" To: systemtap@sourceware.org Subject: [Bug runtime/29756] New: stap -L regexp match broken on some arches Date: Mon, 07 Nov 2022 10:35:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: systemtap X-Bugzilla-Component: runtime X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: mcermak 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 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D29756 Bug ID: 29756 Summary: stap -L regexp match broken on some arches Product: systemtap Version: unspecified Status: NEW Severity: normal Priority: P2 Component: runtime Assignee: systemtap at sourceware dot org Reporter: mcermak at redhat dot com Target Milestone: --- On some arches (interestingly, this only seems to be a problem on ppc64le a= nd s390x, but not on x86_64 or aarch64) the stap -L regexp match doesn't work = for a function name in case the source file isn't specified. If the source fil= e is specified (a base name without any kind of path is good enough) then the ma= tch works fine. Details: 9 ppc64le # stap -L 'process("/lib64/libc.so.6").function("malloc_init_stat= e")' 9 ppc64le # stap -L 'process("/lib64/libc.so.6").function("malloc_init_state*")' process("/usr/lib64/libc.so.6").function("malloc_init_state@/usr/src/debug/= glibc-2.34-48.el9.ppc64le/malloc/malloc.c:1932") $av:mstate 9 ppc64le # stap -L 'process("/lib64/libc.so.6").function("malloc_init_state@/usr/src/debug/gli= bc-2.34-48.el9.ppc64le/malloc/malloc.c")' process("/usr/lib64/libc.so.6").function("malloc_init_state@/usr/src/debug/= glibc-2.34-48.el9.ppc64le/malloc/malloc.c:1932") $av:mstate 9 ppc64le # stap -L 'process("/lib64/libc.so.6").function("malloc_init_state@malloc.c")' process("/usr/lib64/libc.so.6").function("malloc_init_state@/usr/src/debug/= glibc-2.34-48.el9.ppc64le/malloc/malloc.c:1932") $av:mstate 9 ppc64le # stap -L 'process("/lib64/libc.so.6").function("malloc_init_stat= e")' 9 ppc64le # This is with kernel 5.14.0-186.kpq1.el9.ppc64le and stap upstream commit e51e989e33b0f0a0cf26d00755340cef3c2ea81f . --=20 You are receiving this mail because: You are the assignee for the bug.=