Re: [PATCH] perf tests: Don't retest sections in "Object code reading"

[James Clark <james.clark@linaro.org>]

On 08/10/2025 9:32 am, James Clark wrote:
> 
> 
> On 07/10/2025 9:01 pm, Arnaldo Carvalho de Melo wrote:
>> On Tue, Oct 07, 2025 at 10:10:12AM +0100, James Clark wrote:
>>> On 06/10/2025 4:21 pm, Ian Rogers wrote:
>>>> On Mon, Oct 6, 2025 at 6:11 AM James Clark <james.clark@linaro.org> 
>>>> wrote:
>>>>> +       data = zalloc(sizeof(*data));
>>>>> +       if (!data)
>>>>> +               return true;
>>
>>>>> +       data->addr = addr;
>>>>> +       strlcpy(data->path, path, sizeof(data->path));
>>>> nit: perhaps strdup rather than having 4kb per tested_section.
>>
>>> Oh yeah that would have been better, not sure why I didn't do it that 
>>> way.
>>> Although the max sections I saw was around 50, and it's usually a lot 
>>> less
>>> so it's probably not worth the churn to change it now that Arnaldo's 
>>> applied
>>> it?
>>
>> I see you submitted a patch for using strdup() and then there is a need
>> for checking the strdup(), etc.
>>
>> Since at this point this is an improvement on a test and all is sitting
>> in linux-next and the window is closing for v6.18, lets leave this for
>> the next window, ok?
>>
> 
> Makes sense.
> 
>> These would be good things for some tool to catch, before it gets sent,
>> but that is another rabbit hole :-)
>>
>> Thanks,
>>
>> - Arnaldo
> 
> Does Smatch work on Perf? I imagine it would catch this if it does. Or 
> just plain old cppcheck. I'll take a look.
> 
> James
> 

Smatch doesn't know about strdup and seems to be more focused on kernel 
so probably isn't a good fit.

Cppcheck struggles with a lot of the kernely style that's used in Perf, 
especially the headers. We'd either have to silence a lot of the 
warnings, or start with almost no warnings enabled.

It doesn't have a warning for usage of a malloc return value without 
NULL checking, so in this case it wouldn't be useful.

I'm not 100% convinced that the effort of integrating one of these into 
the build system would be worth it. I know that once they're in, there 
would be constant maintenance of silencing false positives etc. And a 
lot of the warnings are more style or opinions about undefined behavior 
according to the standard, but aren't real based on what the compiler 
actually does.

As an example, cppcheck on code-reading.c with --enable=all gives 17 
portability, 11 style, 3 warning and 1 error outputs. Out of all of 
these only two of the warnings are significant, from commit 0f9ad973b095 
("perf tests code-reading: Handle change in objdump output from binutils 
 >= 2.41 on riscv"):

   token = strsep(&version, ".");
   version_tmp = atoi(token);
   if (token)
       version_num += version_tmp * 100;

   token = strsep(&version, ".");
   version_tmp = atoi(token);
   if (token)
       version_num += version_tmp;
			
"token" has already been passed to atoi() so can't be NULL in the if 
statement. I think the atoi() needs to come after the null check.

James