> On 14-Sep-2023, at 11:54 PM, Adrian Hunter <adrian.hun...@intel.com> wrote:
>
> On 7/09/23 19:45, Athira Rajeev wrote:
>> The testcase "Object code reading" fails in somecases
>> for "fs_something" sub test as below:
>>
>> Reading object code for memory address: 0xc008000007f0142c
>> File is: /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko
>> On file address is: 0x1114cc
>> Objdump command is: objdump -z -d --start-address=0x11142c
>> --stop-address=0x1114ac /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko
>> objdump read too few bytes: 128
>> test child finished with -1
>>
>> This can alo be reproduced when running perf record with
>> workload that exercises fs_something() code. In the test
>> setup, this is exercising xfs code since root is xfs.
>>
>> # perf record ./a.out
>> # perf report -v |grep "xfs.ko"
>> 0.76% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko
>> 0xc008000007de5efc B [k] xlog_cil_commit
>> 0.74% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko
>> 0xc008000007d5ae18 B [k] xfs_btree_key_offset
>> 0.74% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko
>> 0xc008000007e11fd4 B [k] 0x0000000000112074
>>
>> Here addr "0xc008000007e11fd4" is not resolved. since this is a
>> kernel module, its offset is from the DSO. Xfs module is loaded
>> at 0xc008000007d00000
>>
>> # cat /proc/modules | grep xfs
>> xfs 2228224 3 - Live 0xc008000007d00000
>>
>> And size is 0x220000. So its loaded between 0xc008000007d00000
>> and 0xc008000007f20000. From objdump, text section is:
>> text 0010f7bc 0000000000000000 0000000000000000 000000a0 2**4
>>
>> Hence perf captured ip maps to 0x112074 which is:
>> ( ip - start of module ) + a0
>>
>> This offset 0x112074 falls out .text section which is up to 0x10f7bc
>> In this case for module, the address 0xc008000007e11fd4 is pointing
>> to stub instructions. This address range represents the module stubs
>> which is allocated on module load and hence is not part of DSO offset.
>>
>> To address this issue in "object code reading", skip the sample if
>> address falls out of text section and is within the module end.
>> Use the "text_end" member of "struct dso" to do this check.
>>
>> To address this issue in "perf report", exploring an option of
>> having stubs range as part of the /proc/kallsyms, so that perf
>> report can resolve addresses in stubs range
>>
>> However this patch uses text_end to skip the stub range for
>> Object code reading testcase.
>>
>> Reported-by: Disha Goel <disg...@linux.ibm.com>
>> Signed-off-by: Athira Rajeev <atraj...@linux.vnet.ibm.com>
>> ---
>> Changelog:
>> v1 -> v2:
>> Updated comment to add description on which arch has stub and
>> reason for skipping as suggested by Adrian
>>
>> tools/perf/tests/code-reading.c | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/tools/perf/tests/code-reading.c
>> b/tools/perf/tests/code-reading.c
>> index ed3815163d1b..3cf6c2d42416 100644
>> --- a/tools/perf/tests/code-reading.c
>> +++ b/tools/perf/tests/code-reading.c
>> @@ -269,6 +269,18 @@ static int read_object_code(u64 addr, size_t len, u8
>> cpumode,
>> if (addr + len > map__end(al.map))
>> len = map__end(al.map) - addr;
>>
>> + /*
>> + * Some architectures (ex: powerpc) have stubs (trampolines) in kernel
>> + * modules to manage long jumps. Check if the ip offset falls in stubs
>> + * sections for kernel modules. And skip module address after text end
>> + */
>> + if (strstr(dso->long_name, ".ko")) {
>
> Sorry for slow reply
>
> !strtailcmp() is slightly better here
>
>> + if (al.addr > dso->text_end) {
>
> We normally avoid nesting if-statements e.g.
>
> if (!strtailcmp(dso->long_name, ".ko") && al.addr > dso->text_end)
>
> Make those changes and you can add:
>
> Reviewed-by: Adrian Hunter <adrian.hun...@intel.com>
Sure, will post a V3 with this change
Athira
>
>
>> + pr_debug("skipping the module address %#"PRIx64" after text end\n",
>> al.addr);
>> + goto out;
>> + }
>> + }
>> +
>> /* Read the object code using perf */
>> ret_len = dso__data_read_offset(dso, maps__machine(thread__maps(thread)),
>> al.addr, buf1, len);
