> On 27-Sep-2023, at 8:25 PM, Athira Rajeev <atraj...@linux.vnet.ibm.com> wrote:
>
>
>
>> On 27-Sep-2023, at 5:45 AM, Namhyung Kim <namhy...@kernel.org> wrote:
>>
>> On Thu, Sep 14, 2023 at 10:40 PM Athira Rajeev
>> <atraj...@linux.vnet.ibm.com> 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>
>>> Tested-by: Disha Goel<disg...@linux.ibm.com>
>>> Reviewed-by: Adrian Hunter <adrian.hun...@intel.com>
>>> ---
>>> Changelog:
>>> v3 -> v4:
>>> Fixed indent in V3
>>>
>>> v2 -> v3:
>>> Used strtailcmp in comparison for module check and added Reviewed-by
>>> from Adrian, Tested-by from Disha.
>>>
>>> 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 | 10 ++++++++++
>>> 1 file changed, 10 insertions(+)
>>>
>>> diff --git a/tools/perf/tests/code-reading.c
>>> b/tools/perf/tests/code-reading.c
>>> index ed3815163d1b..9e6e6c985840 100644
>>> --- a/tools/perf/tests/code-reading.c
>>> +++ b/tools/perf/tests/code-reading.c
>>> @@ -269,6 +269,16 @@ 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 (!strtailcmp(dso->long_name, ".ko") && al.addr > dso->text_end) {
>>
>> There's a is_kernel_module() that can check compressed modules
>> too but I think we need a simpler way to check it like dso->kernel.
>>
>> Thanks,
>> Namhyung
>
> Thanks for the comment Namhyung. I will add similar to dso->kernel, another
> field check in next version of patchset
>
> Athira
Hi Namhyung,
I have posted a V5 for this:
https://lore.kernel.org/linux-perf-users/20230928075213.84392-1-atraj...@linux.vnet.ibm.com/T/#t
Thanks
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);
>>> --
>>> 2.31.1
