Re: [V2 2/2] tools/perf/tests: Fix object code reading to skip address that falls out of text section
> On 14-Sep-2023, at 11:54 PM, Adrian Hunter 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: 0xc00807f0142c >>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 >> 0xc00807de5efc B [k] xlog_cil_commit >> 0.74% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko >> 0xc00807d5ae18 B [k] xfs_btree_key_offset >> 0.74% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko >> 0xc00807e11fd4 B [k] 0x00112074 >> >> Here addr "0xc00807e11fd4" is not resolved. since this is a >> kernel module, its offset is from the DSO. Xfs module is loaded >> at 0xc00807d0 >> >> # cat /proc/modules | grep xfs >>xfs 2228224 3 - Live 0xc00807d0 >> >> And size is 0x22. So its loaded between 0xc00807d0 >> and 0xc00807f2. From objdump, text section is: >>text 0010f7bc 00a0 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 0xc00807e11fd4 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 >> Signed-off-by: Athira Rajeev >> --- >> 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 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);
Re: [V2 2/2] tools/perf/tests: Fix object code reading to skip address that falls out of text section
On 07/09/23 10:15 pm, Athira Rajeev wrote: The testcase "Object code reading" fails in somecases for "fs_something" sub test as below: Reading object code for memory address: 0xc00807f0142c 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 0xc00807de5efc B [k] xlog_cil_commit 0.74% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko 0xc00807d5ae18 B [k] xfs_btree_key_offset 0.74% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko 0xc00807e11fd4 B [k] 0x00112074 Here addr "0xc00807e11fd4" is not resolved. since this is a kernel module, its offset is from the DSO. Xfs module is loaded at 0xc00807d0 # cat /proc/modules | grep xfs xfs 2228224 3 - Live 0xc00807d0 And size is 0x22. So its loaded between 0xc00807d0 and 0xc00807f2. From objdump, text section is: text 0010f7bc 00a0 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 0xc00807e11fd4 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 Signed-off-by: Athira Rajeev --- Changelog: v1 -> v2: Updated comment to add description on which arch has stub and reason for skipping as suggested by Adrian With this patch applied perf Object code reading test works correctly. 26: Object code reading : Ok Tested-by: Disha Goel 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")) { + if (al.addr > dso->text_end) { + 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);
Re: [V2 2/2] tools/perf/tests: Fix object code reading to skip address that falls out of text section
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: 0xc00807f0142c > 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 > 0xc00807de5efc B [k] xlog_cil_commit > 0.74% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko > 0xc00807d5ae18 B [k] xfs_btree_key_offset > 0.74% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko > 0xc00807e11fd4 B [k] 0x00112074 > > Here addr "0xc00807e11fd4" is not resolved. since this is a > kernel module, its offset is from the DSO. Xfs module is loaded > at 0xc00807d0 > ># cat /proc/modules | grep xfs > xfs 2228224 3 - Live 0xc00807d0 > > And size is 0x22. So its loaded between 0xc00807d0 > and 0xc00807f2. From objdump, text section is: > text 0010f7bc 00a0 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 0xc00807e11fd4 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 > Signed-off-by: Athira Rajeev > --- > 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 > + 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);
Re: [V2 2/2] tools/perf/tests: Fix object code reading to skip address that falls out of text section
> On 14-Sep-2023, at 5:47 PM, Disha Goel wrote: > > On 07/09/23 10:15 pm, Athira Rajeev wrote: >> The testcase "Object code reading" fails in somecases >> for "fs_something" sub test as below: >> >> Reading object code for memory address: 0xc00807f0142c >> 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 0xc00807de5efc >> B [k] xlog_cil_commit >> 0.74% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko 0xc00807d5ae18 >> B [k] xfs_btree_key_offset >> 0.74% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko 0xc00807e11fd4 >> B [k] 0x00112074 >> >> Here addr "0xc00807e11fd4" is not resolved. since this is a >> kernel module, its offset is from the DSO. Xfs module is loaded >> at 0xc00807d0 >> >> # cat /proc/modules | grep xfs >> xfs 2228224 3 - Live 0xc00807d0 >> >> And size is 0x22. So its loaded between ߦ0xc00807d0 >> and 0xc00807f2. From objdump, text section is: >> text 0010f7bc 00a0 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 0xc00807e11fd4 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 >> Signed-off-by: Athira Rajeev >> --- >> Changelog: >> v1 -> v2: >> Updated comment to add description on which arch has stub and >> reason for skipping as suggested by Adrian Thanks for testing Disha. Hi Adrian, Can you please review and share feedback on this version. Thanks Athira > With this patch applied perf Object code reading test works correctly. > > 26: Object code reading : Ok > > Tested-by: Disha Goel > >> 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")) { >> + if (al.addr > dso->text_end) { >> + 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); >>
[V2 2/2] tools/perf/tests: Fix object code reading to skip address that falls out of text section
The testcase "Object code reading" fails in somecases for "fs_something" sub test as below: Reading object code for memory address: 0xc00807f0142c 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 0xc00807de5efc B [k] xlog_cil_commit 0.74% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko 0xc00807d5ae18 B [k] xfs_btree_key_offset 0.74% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko 0xc00807e11fd4 B [k] 0x00112074 Here addr "0xc00807e11fd4" is not resolved. since this is a kernel module, its offset is from the DSO. Xfs module is loaded at 0xc00807d0 # cat /proc/modules | grep xfs xfs 2228224 3 - Live 0xc00807d0 And size is 0x22. So its loaded between 0xc00807d0 and 0xc00807f2. From objdump, text section is: text 0010f7bc 00a0 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 0xc00807e11fd4 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 Signed-off-by: Athira Rajeev --- 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")) { + if (al.addr > dso->text_end) { + 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
Re: [PATCH V2 2/2] tools/perf/tests: Fix object code reading to skip address that falls out of text section
> On 18-Aug-2023, at 12:45 PM, Adrian Hunter wrote: > > On 17/08/23 20:18, Athira Rajeev wrote: >> The testcase "Object code reading" fails in somecases >> for "fs_something" sub test as below: >> >>Reading object code for memory address: 0xc00807f0142c >>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 >> 0xc00807de5efc B [k] xlog_cil_commit >> 0.74% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko >> 0xc00807d5ae18 B [k] xfs_btree_key_offset >> 0.74% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko >> 0xc00807e11fd4 B [k] 0x00112074 >> >> Here addr "0xc00807e11fd4" is not resolved. since this is a >> kernel module, its offset is from the DSO. Xfs module is loaded >> at 0xc00807d0 >> >> # cat /proc/modules | grep xfs >>xfs 2228224 3 - Live 0xc00807d0 >> >> And size is 0x22. So its loaded between 0xc00807d0 >> and 0xc00807f2. From objdump, text section is: >>text 0010f7bc 00a0 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 0xc00807e11fd4 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 >> Signed-off-by: Athira Rajeev >> --- >> tools/perf/tests/code-reading.c | 8 >> 1 file changed, 8 insertions(+) >> >> diff --git a/tools/perf/tests/code-reading.c >> b/tools/perf/tests/code-reading.c >> index ed3815163d1b..911f8fa13677 100644 >> --- a/tools/perf/tests/code-reading.c >> +++ b/tools/perf/tests/code-reading.c >> @@ -269,6 +269,14 @@ 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; >> >> + /* Check if the ip offset falls in stubs sections for kernel modules */ > > What arches have stubs - maybe expand the comment a bit e.g. > "Some architectures (such as blah blah) have stubs (trampolines) in kernel > modules to manage long jumps” Ok > >> + if (strstr(dso->long_name, ".ko")) { >> + if ((al.addr < map__end(al.map)) && (al.addr > dso->text_end)) { > > Why check al.addr < map__end(al.map) ? addr must be on the map mustn't it? Yes, you are right. > > Also please remove redundant parentheses. > >> + pr_debug(" - skipping\n"); > > "skipping" but why. Maybe "skipping module address after text end" Sure, will post V2 with these changes Thanks Athira > >> + goto out; >> + } >> + } >> + >> /* Read the object code using perf */ >> ret_len = dso__data_read_offset(dso, maps__machine(thread__maps(thread)), >> al.addr, buf1, len);
Re: [PATCH V2 2/2] tools/perf/tests: Fix object code reading to skip address that falls out of text section
On 17/08/23 20:18, Athira Rajeev wrote: > The testcase "Object code reading" fails in somecases > for "fs_something" sub test as below: > > Reading object code for memory address: 0xc00807f0142c > 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 > 0xc00807de5efc B [k] xlog_cil_commit > 0.74% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko > 0xc00807d5ae18 B [k] xfs_btree_key_offset > 0.74% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko > 0xc00807e11fd4 B [k] 0x00112074 > > Here addr "0xc00807e11fd4" is not resolved. since this is a > kernel module, its offset is from the DSO. Xfs module is loaded > at 0xc00807d0 > ># cat /proc/modules | grep xfs > xfs 2228224 3 - Live 0xc00807d0 > > And size is 0x22. So its loaded between 0xc00807d0 > and 0xc00807f2. From objdump, text section is: > text 0010f7bc 00a0 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 0xc00807e11fd4 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 > Signed-off-by: Athira Rajeev > --- > tools/perf/tests/code-reading.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/tools/perf/tests/code-reading.c b/tools/perf/tests/code-reading.c > index ed3815163d1b..911f8fa13677 100644 > --- a/tools/perf/tests/code-reading.c > +++ b/tools/perf/tests/code-reading.c > @@ -269,6 +269,14 @@ 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; > > + /* Check if the ip offset falls in stubs sections for kernel modules */ What arches have stubs - maybe expand the comment a bit e.g. "Some architectures (such as blah blah) have stubs (trampolines) in kernel modules to manage long jumps" > + if (strstr(dso->long_name, ".ko")) { > + if ((al.addr < map__end(al.map)) && (al.addr > dso->text_end)) { Why check al.addr < map__end(al.map) ? addr must be on the map mustn't it? Also please remove redundant parentheses. > + pr_debug(" - skipping\n"); "skipping" but why. Maybe "skipping module address after text end" > + goto out; > + } > + } > + > /* Read the object code using perf */ > ret_len = dso__data_read_offset(dso, > maps__machine(thread__maps(thread)), > al.addr, buf1, len);
[PATCH V2 2/2] tools/perf/tests: Fix object code reading to skip address that falls out of text section
The testcase "Object code reading" fails in somecases for "fs_something" sub test as below: Reading object code for memory address: 0xc00807f0142c 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 0xc00807de5efc B [k] xlog_cil_commit 0.74% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko 0xc00807d5ae18 B [k] xfs_btree_key_offset 0.74% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko 0xc00807e11fd4 B [k] 0x00112074 Here addr "0xc00807e11fd4" is not resolved. since this is a kernel module, its offset is from the DSO. Xfs module is loaded at 0xc00807d0 # cat /proc/modules | grep xfs xfs 2228224 3 - Live 0xc00807d0 And size is 0x22. So its loaded between 0xc00807d0 and 0xc00807f2. From objdump, text section is: text 0010f7bc 00a0 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 0xc00807e11fd4 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 Signed-off-by: Athira Rajeev --- tools/perf/tests/code-reading.c | 8 1 file changed, 8 insertions(+) diff --git a/tools/perf/tests/code-reading.c b/tools/perf/tests/code-reading.c index ed3815163d1b..911f8fa13677 100644 --- a/tools/perf/tests/code-reading.c +++ b/tools/perf/tests/code-reading.c @@ -269,6 +269,14 @@ 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; + /* Check if the ip offset falls in stubs sections for kernel modules */ + if (strstr(dso->long_name, ".ko")) { + if ((al.addr < map__end(al.map)) && (al.addr > dso->text_end)) { + pr_debug(" - skipping\n"); + 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