From: Athira Rajeev <atrajeev@linux.ibm.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: acme@kernel.org, jolsa@kernel.org, adrian.hunter@intel.com,
vmolnaro@redhat.com, mpetlan@redhat.com, tmricht@linux.ibm.com,
maddy@linux.ibm.com, irogers@google.com,
linux-perf-users@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
hbathini@linux.vnet.ibm.com, Tejas.Manhas1@ibm.com,
Tanushree.Shah@ibm.com, Shivani.Nittor@ibm.com
Subject: Re: [PATCH V2] tools/perf/tests: Update test_adding_kernel.sh to handle proper debuginfo check
Date: Tue, 31 Mar 2026 15:42:13 +0530 [thread overview]
Message-ID: <8A51316A-D448-4468-AD4B-B33395FDC0D8@linux.ibm.com> (raw)
In-Reply-To: <actwKNAzk6PnoBDX@google.com>
> On 31 Mar 2026, at 12:26 PM, Namhyung Kim <namhyung@kernel.org> wrote:
>
> On Fri, Mar 27, 2026 at 11:26:48PM +0530, Athira Rajeev wrote:
>>
>>
>>> On 27 Mar 2026, at 4:43 AM, Namhyung Kim <namhyung@kernel.org> wrote:
>>>
>>> On Mon, Mar 23, 2026 at 05:54:24PM +0530, Athira Rajeev wrote:
>>>> Perf test perftool-testsuite_probe fails as below:
>>>>
>>>> Regexp not found: "\s*probe:inode_permission(?:_\d+)?\s+\(on inode_permission(?:[:\+][0-9A-Fa-f]+)?@.+\)"
>>>> -- [ FAIL ] -- perf_probe :: test_adding_kernel :: listing added probe :: perf probe -l (output regexp parsing)
>>>> -- [ PASS ] -- perf_probe :: test_adding_kernel :: removing multiple probes
>>>> Regexp not found: "probe:vfs_mknod"
>>>> Regexp not found: "probe:vfs_create"
>>>> Regexp not found: "probe:vfs_rmdir"
>>>> Regexp not found: "probe:vfs_link"
>>>> Regexp not found: "probe:vfs_write"
>>>> -- [ FAIL ] -- perf_probe :: test_adding_kernel :: wildcard adding support (command exitcode + output regexp parsing)
>>>> Regexp not found: "somenonexistingrandomstuffwhichisalsoprettylongorevenlongertoexceed64"
>>>> Regexp not found: "in this function|at this address"
>>>> -- [ FAIL ] -- perf_probe :: test_adding_kernel :: non-existing variable (output regexp parsing)
>>>> ## [ FAIL ] ## perf_probe :: test_adding_kernel SUMMARY :: 3 failures found
>>>>
>>>> Further analysing, the failed testcase is for "test_adding_kernel".
>>>> If the kernel debuginfo is missing, perf probe fails as below:
>>>>
>>>> perf probe -nf --max-probes=512 -a 'vfs_* $params'
>>>> Failed to find the path for the kernel: No such file or directory
>>>> Error: Failed to add events.
>>>>
>>>> skip_if_no_debuginfo has check to handle whether debuginfo is present
>>>> and the testcase checks for debuginfo since this :
>>>> commit 90d32e92011e ("tools/perf: Handle perftool-testsuite_probe
>>>> testcases fail when kernel debuginfo is not present")
>>>>
>>>> Recently a change got added in "tests/shell/lib/probe_vfs_getname.sh"
>>>> via this another fix:
>>>> commit 92b664dcefab ("perf test probe_vfs_getname: Skip if no suitable
>>>> line detected")
>>>> Since this commit, first add_probe_vfs_getname is used to prevent false
>>>> failures. And based on return code of add_probe_vfs_getname, skip_if_no_debuginfo
>>>> is used to skip testcase if debuginfo is present. And this modified other
>>>> testcases to call add_probe_vfs_getname first and invoke
>>>> skip_if_no_debuginfo based on return value.
>>>>
>>>> The tests in test_adding_kernel.sh which depends on presence of
>>>> debuginfo are:
>>>> 1. probe add for inode_permission
>>>> 2. probe max-probes option using 'vfs_* $params'
>>>> 3. non-existing variable probing
>>>>
>>>> For these tests, probe check for specific line is not required.
>>>> So call skip_if_no_debuginfo with argument to say if line check is
>>>> needed. This is to convey to skip_if_no_debuginfo() function
>>>> that test only needs to check for debuginfo, and not specifically
>>>> line number. Update skip_if_no_debuginfo to use simple "perf probe"
>>>> check if test only needs to check for debuginfo. And for other
>>>> tests which rely on line number, use add_probe_vfs_getname()
>>>>
>>>> With the change, verified that only three which required debuginfo only
>>>> is skipped and others ran successfully. Also tested with debuginfo
>>>> to make sure tests are not skipped.
>>>>
>>>> Reported-by: Tejas Manhas <Tejas.Manhas1@ibm.com>
>>>> Reviewed-by: Ian Rogers <irogers@google.com>
>>>> Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
>>>> ---
>>>> Changelog:
>>>> - First version used "perf probe -v -L getname_flags" for debuginfo
>>>> check. This will not catch fail string "Debuginfo-analysis is not
>>>> supported" which is used in cases when perf is built without dwarf.
>>>> So use "perf probe -vn add inode_permission" to capture cases when
>>>> tools built with NO_LIBDWARF=1. This will capture debuginfo missing as
>>>> well as tool built without dwarf case.
>>>>
>>>> .../tests/shell/base_probe/test_adding_kernel.sh | 15 ++++++++++++++-
>>>> tools/perf/tests/shell/lib/probe_vfs_getname.sh | 13 ++++++++++++-
>>>> 2 files changed, 26 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/tools/perf/tests/shell/base_probe/test_adding_kernel.sh b/tools/perf/tests/shell/base_probe/test_adding_kernel.sh
>>>> index 555a825d55f2..f3db125c8669 100755
>>>> --- a/tools/perf/tests/shell/base_probe/test_adding_kernel.sh
>>>> +++ b/tools/perf/tests/shell/base_probe/test_adding_kernel.sh
>>>> @@ -23,10 +23,23 @@ TEST_RESULT=0
>>>> . "$DIR_PATH/../lib/probe_vfs_getname.sh"
>>>>
>>>> TEST_PROBE=${TEST_PROBE:-"inode_permission"}
>>>> +PROBE_NO_LINE_CHECK=1
>>>
>>> I'm not sure I follow but shouldn't it depend on the return value of
>>> `perf check feature -q dwarf`?
>>>
>>> Thanks,
>>> Namhyung
>>
>> Hi Namhyung
>>
>> Thanks for checking the patch.
>>
>> Yes, "perf check feature -q dwarf” checks if perf is compiled with dwarf support.
>> But for “test_adding_kernel” , we need to check if kernel debuginfo is missing.
>> The check this path is trying to, also includes “debuginfo”
>>
>> In environment without debuginfo: perftool-testsuite_probe fails as below:
>>
>> Regexp not found: "\s*probe:inode_permission(?:_\d+)?\s+\(on inode_permission(?:[:\+][0-9A-Fa-f]+)?@.+\)"
>> -- [ FAIL ] -- perf_probe :: test_adding_kernel :: listing added probe :: perf probe -l (output regexp parsing)
>> -- [ PASS ] -- perf_probe :: test_adding_kernel :: removing multiple probes
>> Regexp not found: "probe:vfs_mknod"
>> Regexp not found: "probe:vfs_create"
>> Regexp not found: "probe:vfs_rmdir"
>> Regexp not found: "probe:vfs_link"
>> Regexp not found: "probe:vfs_write"
>> -- [ FAIL ] -- perf_probe :: test_adding_kernel :: wildcard adding support (command exitcode + output regexp parsing)
>> Regexp not found: "somenonexistingrandomstuffwhichisalsoprettylongorevenlongertoexceed64"
>> Regexp not found: "in this function|at this address"
>> -- [ FAIL ] -- perf_probe :: test_adding_kernel :: non-existing variable (output regexp parsing)
>> ## [ FAIL ] ## perf_probe :: test_adding_kernel SUMMARY :: 3 failures found
>>
>> We have “skip_if_no_debuginfo” check in tools/perf/tests/shell/lib/probe_vfs_getname.sh and
>> “test_adding_kernel” calls this to find out presence of debuginfo.
>>
>> Recently a change got added via commit 92b664dcefab ("perf test probe_vfs_getname: Skip if no suitable
>> line detected”) where we return if specific line is not found using perf probe. And hence debuginfo check is not
>> happening.
>>
>>
>> The tests in test_adding_kernel.sh which depends on presence of
>> debuginfo are:
>> 1. probe add for inode_permission
>> 2. probe max-probes option using 'vfs_* $params'
>> 3. non-existing variable probing
>>
>> For these tests, probe check for specific line is not required. So this patch updates
>> skip_if_no_debuginfo to use an argument that communicates whether line check is needed.
>> If only debuginfo/dwarf check is required, use simple "perf probe”. And for other
>> tests which rely on line number, fallback to default add_probe_vfs_getname().
>
> Ok, thanks for the explanation. But I'm afraid you didn't change other
> callsites to pass 0 explicitly.
Thanks Namhyung for responding. I will add those changes in V3
Thanks
Athira
>
>>>
>>>>
>>>> # set NO_DEBUGINFO to skip testcase if debuginfo is not present
>>>> # skip_if_no_debuginfo returns 2 if debuginfo is not present
>>>> -skip_if_no_debuginfo
>>>> +#
>>>> +# The perf probe checks which depends on presence of debuginfo and
>>>> +# used in this testcase are:
>>>> +# 1. probe add for inode_permission
>>>> +# 2. probe max-probes option using 'vfs_* $params'
>>>> +# 3. non-existing variable probing
>>>> +#
>>>> +# For these tests, probe check for specific line is not
>>>> +# required ( add_probe_vfs_getname does that ). So call
>>>> +# skip_if_no_debuginfo with argument as 1. This is to convey
>>>> +# that test only needs to check for debuginfo, and not specifically
>>>> +# line number
>>>> +skip_if_no_debuginfo $PROBE_NO_LINE_CHECK
>>>> if [ $? -eq 2 ]; then
>>>> NO_DEBUGINFO=1
>>>> fi
>>>> diff --git a/tools/perf/tests/shell/lib/probe_vfs_getname.sh b/tools/perf/tests/shell/lib/probe_vfs_getname.sh
>>>> index 88cd0e26d5f6..8ae2ea2bc8a2 100644
>>>> --- a/tools/perf/tests/shell/lib/probe_vfs_getname.sh
>>>> +++ b/tools/perf/tests/shell/lib/probe_vfs_getname.sh
>>>> @@ -39,7 +39,18 @@ add_probe_vfs_getname() {
>>>> }
>>>>
>>>> skip_if_no_debuginfo() {
>>>> - add_probe_vfs_getname -v 2>&1 | grep -E -q "^(Failed to find the path for the kernel|Debuginfo-analysis is not supported)|(file has no debug information)" && return 2
>>>> + no_line_check=$1
>>>> + debug_str="^(Failed to find the path for the kernel|Debuginfo-analysis is not supported)|(file has no debug information)"
>>>> +
>>>> + # search for debug_str using simple perf probe if the
>>>> + # test only needs to check for debuginfo, and not specifically
>>>> + # line number.
>>>> + if [ $no_line_check -eq 1 ]; then
>>>> + perf probe -vn add inode_permission 2>&1 | grep -E -q "$debug_str" && return 2
>
> Sashiko found that it should be '--add' or '-a'.
>
> Thanks,
> Namhyung
>
>
>>>> + else
>>>> + add_probe_vfs_getname -v 2>&1 | grep -E -q "$debug_str" && return 2
>>>> + fi
>>>> +
>>>> return 1
>>>> }
>>>>
>>>> --
>>>> 2.47.3
prev parent reply other threads:[~2026-03-31 10:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-23 12:24 [PATCH V2] tools/perf/tests: Update test_adding_kernel.sh to handle proper debuginfo check Athira Rajeev
2026-03-26 23:13 ` Namhyung Kim
2026-03-27 17:56 ` Athira Rajeev
2026-03-31 6:56 ` Namhyung Kim
2026-03-31 10:12 ` Athira Rajeev [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8A51316A-D448-4468-AD4B-B33395FDC0D8@linux.ibm.com \
--to=atrajeev@linux.ibm.com \
--cc=Shivani.Nittor@ibm.com \
--cc=Tanushree.Shah@ibm.com \
--cc=Tejas.Manhas1@ibm.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=hbathini@linux.vnet.ibm.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mpetlan@redhat.com \
--cc=namhyung@kernel.org \
--cc=tmricht@linux.ibm.com \
--cc=vmolnaro@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox