* [PATCH V4 1/2] tools/perf: Add text_end to "struct dso" to save .text section size
@ 2023-09-15 5:37 ` Athira Rajeev
0 siblings, 0 replies; 14+ messages in thread
From: Athira Rajeev @ 2023-09-15 5:37 UTC (permalink / raw)
To: acme, jolsa, adrian.hunter, irogers, namhyung
Cc: linux-perf-users, linuxppc-dev, maddy, atrajeev, kjain, disgoel,
Disha Goel
Update "struct dso" to include new member "text_end".
This new field will represent the offset for end of text
section for a dso. For elf, this value is derived as:
sh_size (Size of section in byes) + sh_offset (Section file
offst) of the elf header for text.
For bfd, this value is derived as:
1. For PE file,
section->size + ( section->vma - dso->text_offset)
2. Other cases:
section->filepos (file position) + section->size (size of
section)
To resolve the address from a sample, perf looks at the
DSO maps. In case of address from a kernel module, there
were some address found to be not resolved. This was
observed while running perf test for "Object code reading".
Though the ip falls beteen the start address of the loaded
module (perf map->start ) and end address ( perf map->end),
it was unresolved.
Example:
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
Here, module is loaded at:
# cat /proc/modules | grep xfs
xfs 2228224 3 - Live 0xc008000007d00000
From objdump for xfs module, text section is:
text 0010f7bc 0000000000000000 0000000000000000 000000a0 2**4
Here the offset for 0xc008000007f0142c ie 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 identify such address, which falls out of text
section and within module end, added the new field "text_end" to
"struct dso".
Reported-by: Disha Goel <disgoel@linux.ibm.com>
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
---
Changelog:
v2 -> v3:
Added Reviewed-by from Adrian
v1 -> v2:
Added text_end for bfd also by updating dso__load_bfd_symbols
as suggested by Adrian.
tools/perf/util/dso.h | 1 +
tools/perf/util/symbol-elf.c | 4 +++-
tools/perf/util/symbol.c | 2 ++
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
index b41c9782c754..70fe0fe69bef 100644
--- a/tools/perf/util/dso.h
+++ b/tools/perf/util/dso.h
@@ -181,6 +181,7 @@ struct dso {
u8 rel;
struct build_id bid;
u64 text_offset;
+ u64 text_end;
const char *short_name;
const char *long_name;
u16 long_name_len;
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 95e99c332d7e..9e7eeaf616b8 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1514,8 +1514,10 @@ dso__load_sym_internal(struct dso *dso, struct map *map, struct symsrc *syms_ss,
}
if (elf_section_by_name(runtime_ss->elf, &runtime_ss->ehdr, &tshdr,
- ".text", NULL))
+ ".text", NULL)) {
dso->text_offset = tshdr.sh_addr - tshdr.sh_offset;
+ dso->text_end = tshdr.sh_offset + tshdr.sh_size;
+ }
if (runtime_ss->opdsec)
opddata = elf_rawdata(runtime_ss->opdsec, NULL);
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 3f36675b7c8f..f25e4e62cf25 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1733,8 +1733,10 @@ int dso__load_bfd_symbols(struct dso *dso, const char *debugfile)
/* PE symbols can only have 4 bytes, so use .text high bits */
dso->text_offset = section->vma - (u32)section->vma;
dso->text_offset += (u32)bfd_asymbol_value(symbols[i]);
+ dso->text_end = (section->vma - dso->text_offset) + section->size;
} else {
dso->text_offset = section->vma - section->filepos;
+ dso->text_end = section->filepos + section->size;
}
}
--
2.31.1
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH V4 1/2] tools/perf: Add text_end to "struct dso" to save .text section size
@ 2023-09-15 5:37 ` Athira Rajeev
0 siblings, 0 replies; 14+ messages in thread
From: Athira Rajeev @ 2023-09-15 5:37 UTC (permalink / raw)
To: acme, jolsa, adrian.hunter, irogers, namhyung
Cc: atrajeev, Disha Goel, kjain, linux-perf-users, maddy, disgoel,
linuxppc-dev
Update "struct dso" to include new member "text_end".
This new field will represent the offset for end of text
section for a dso. For elf, this value is derived as:
sh_size (Size of section in byes) + sh_offset (Section file
offst) of the elf header for text.
For bfd, this value is derived as:
1. For PE file,
section->size + ( section->vma - dso->text_offset)
2. Other cases:
section->filepos (file position) + section->size (size of
section)
To resolve the address from a sample, perf looks at the
DSO maps. In case of address from a kernel module, there
were some address found to be not resolved. This was
observed while running perf test for "Object code reading".
Though the ip falls beteen the start address of the loaded
module (perf map->start ) and end address ( perf map->end),
it was unresolved.
Example:
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
Here, module is loaded at:
# cat /proc/modules | grep xfs
xfs 2228224 3 - Live 0xc008000007d00000
From objdump for xfs module, text section is:
text 0010f7bc 0000000000000000 0000000000000000 000000a0 2**4
Here the offset for 0xc008000007f0142c ie 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 identify such address, which falls out of text
section and within module end, added the new field "text_end" to
"struct dso".
Reported-by: Disha Goel <disgoel@linux.ibm.com>
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
---
Changelog:
v2 -> v3:
Added Reviewed-by from Adrian
v1 -> v2:
Added text_end for bfd also by updating dso__load_bfd_symbols
as suggested by Adrian.
tools/perf/util/dso.h | 1 +
tools/perf/util/symbol-elf.c | 4 +++-
tools/perf/util/symbol.c | 2 ++
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
index b41c9782c754..70fe0fe69bef 100644
--- a/tools/perf/util/dso.h
+++ b/tools/perf/util/dso.h
@@ -181,6 +181,7 @@ struct dso {
u8 rel;
struct build_id bid;
u64 text_offset;
+ u64 text_end;
const char *short_name;
const char *long_name;
u16 long_name_len;
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 95e99c332d7e..9e7eeaf616b8 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1514,8 +1514,10 @@ dso__load_sym_internal(struct dso *dso, struct map *map, struct symsrc *syms_ss,
}
if (elf_section_by_name(runtime_ss->elf, &runtime_ss->ehdr, &tshdr,
- ".text", NULL))
+ ".text", NULL)) {
dso->text_offset = tshdr.sh_addr - tshdr.sh_offset;
+ dso->text_end = tshdr.sh_offset + tshdr.sh_size;
+ }
if (runtime_ss->opdsec)
opddata = elf_rawdata(runtime_ss->opdsec, NULL);
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 3f36675b7c8f..f25e4e62cf25 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1733,8 +1733,10 @@ int dso__load_bfd_symbols(struct dso *dso, const char *debugfile)
/* PE symbols can only have 4 bytes, so use .text high bits */
dso->text_offset = section->vma - (u32)section->vma;
dso->text_offset += (u32)bfd_asymbol_value(symbols[i]);
+ dso->text_end = (section->vma - dso->text_offset) + section->size;
} else {
dso->text_offset = section->vma - section->filepos;
+ dso->text_end = section->filepos + section->size;
}
}
--
2.31.1
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH V4 2/2] tools/perf/tests: Fix object code reading to skip address that falls out of text section
2023-09-15 5:37 ` Athira Rajeev
@ 2023-09-15 5:37 ` Athira Rajeev
-1 siblings, 0 replies; 14+ messages in thread
From: Athira Rajeev @ 2023-09-15 5:37 UTC (permalink / raw)
To: acme, jolsa, adrian.hunter, irogers, namhyung
Cc: linux-perf-users, linuxppc-dev, maddy, atrajeev, kjain, disgoel,
Disha Goel
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 <disgoel@linux.ibm.com>
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Tested-by: Disha Goel<disgoel@linux.ibm.com>
Reviewed-by: Adrian Hunter <adrian.hunter@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) {
+ 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
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH V4 2/2] tools/perf/tests: Fix object code reading to skip address that falls out of text section
@ 2023-09-15 5:37 ` Athira Rajeev
0 siblings, 0 replies; 14+ messages in thread
From: Athira Rajeev @ 2023-09-15 5:37 UTC (permalink / raw)
To: acme, jolsa, adrian.hunter, irogers, namhyung
Cc: atrajeev, Disha Goel, kjain, linux-perf-users, maddy, disgoel,
linuxppc-dev
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 <disgoel@linux.ibm.com>
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Tested-by: Disha Goel<disgoel@linux.ibm.com>
Reviewed-by: Adrian Hunter <adrian.hunter@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) {
+ 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
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH V4 1/2] tools/perf: Add text_end to "struct dso" to save .text section size
2023-09-15 5:37 ` Athira Rajeev
@ 2023-09-25 10:36 ` kajoljain
-1 siblings, 0 replies; 14+ messages in thread
From: kajoljain @ 2023-09-25 10:36 UTC (permalink / raw)
To: Athira Rajeev, acme, jolsa, adrian.hunter, irogers, namhyung
Cc: linux-perf-users, linuxppc-dev, maddy, disgoel, Disha Goel
Patch looks good to me.
Reviewed-by: Kajol Jain <kjain@linux.ibm.com>
Thanks,
Kajol Jain
On 9/15/23 11:07, Athira Rajeev wrote:
> Update "struct dso" to include new member "text_end".
> This new field will represent the offset for end of text
> section for a dso. For elf, this value is derived as:
> sh_size (Size of section in byes) + sh_offset (Section file
> offst) of the elf header for text.
>
> For bfd, this value is derived as:
> 1. For PE file,
> section->size + ( section->vma - dso->text_offset)
> 2. Other cases:
> section->filepos (file position) + section->size (size of
> section)
>
> To resolve the address from a sample, perf looks at the
> DSO maps. In case of address from a kernel module, there
> were some address found to be not resolved. This was
> observed while running perf test for "Object code reading".
> Though the ip falls beteen the start address of the loaded
> module (perf map->start ) and end address ( perf map->end),
> it was unresolved.
>
> Example:
>
> 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
>
> Here, module is loaded at:
> # cat /proc/modules | grep xfs
> xfs 2228224 3 - Live 0xc008000007d00000
>
> From objdump for xfs module, text section is:
> text 0010f7bc 0000000000000000 0000000000000000 000000a0 2**4
>
> Here the offset for 0xc008000007f0142c ie 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 identify such address, which falls out of text
> section and within module end, added the new field "text_end" to
> "struct dso".
>
> Reported-by: Disha Goel <disgoel@linux.ibm.com>
> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
> Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
> Changelog:
> v2 -> v3:
> Added Reviewed-by from Adrian
>
> v1 -> v2:
> Added text_end for bfd also by updating dso__load_bfd_symbols
> as suggested by Adrian.
>
> tools/perf/util/dso.h | 1 +
> tools/perf/util/symbol-elf.c | 4 +++-
> tools/perf/util/symbol.c | 2 ++
> 3 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
> index b41c9782c754..70fe0fe69bef 100644
> --- a/tools/perf/util/dso.h
> +++ b/tools/perf/util/dso.h
> @@ -181,6 +181,7 @@ struct dso {
> u8 rel;
> struct build_id bid;
> u64 text_offset;
> + u64 text_end;
> const char *short_name;
> const char *long_name;
> u16 long_name_len;
> diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
> index 95e99c332d7e..9e7eeaf616b8 100644
> --- a/tools/perf/util/symbol-elf.c
> +++ b/tools/perf/util/symbol-elf.c
> @@ -1514,8 +1514,10 @@ dso__load_sym_internal(struct dso *dso, struct map *map, struct symsrc *syms_ss,
> }
>
> if (elf_section_by_name(runtime_ss->elf, &runtime_ss->ehdr, &tshdr,
> - ".text", NULL))
> + ".text", NULL)) {
> dso->text_offset = tshdr.sh_addr - tshdr.sh_offset;
> + dso->text_end = tshdr.sh_offset + tshdr.sh_size;
> + }
>
> if (runtime_ss->opdsec)
> opddata = elf_rawdata(runtime_ss->opdsec, NULL);
> diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> index 3f36675b7c8f..f25e4e62cf25 100644
> --- a/tools/perf/util/symbol.c
> +++ b/tools/perf/util/symbol.c
> @@ -1733,8 +1733,10 @@ int dso__load_bfd_symbols(struct dso *dso, const char *debugfile)
> /* PE symbols can only have 4 bytes, so use .text high bits */
> dso->text_offset = section->vma - (u32)section->vma;
> dso->text_offset += (u32)bfd_asymbol_value(symbols[i]);
> + dso->text_end = (section->vma - dso->text_offset) + section->size;
> } else {
> dso->text_offset = section->vma - section->filepos;
> + dso->text_end = section->filepos + section->size;
> }
> }
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH V4 1/2] tools/perf: Add text_end to "struct dso" to save .text section size
@ 2023-09-25 10:36 ` kajoljain
0 siblings, 0 replies; 14+ messages in thread
From: kajoljain @ 2023-09-25 10:36 UTC (permalink / raw)
To: Athira Rajeev, acme, jolsa, adrian.hunter, irogers, namhyung
Cc: linux-perf-users, Disha Goel, maddy, linuxppc-dev, disgoel
Patch looks good to me.
Reviewed-by: Kajol Jain <kjain@linux.ibm.com>
Thanks,
Kajol Jain
On 9/15/23 11:07, Athira Rajeev wrote:
> Update "struct dso" to include new member "text_end".
> This new field will represent the offset for end of text
> section for a dso. For elf, this value is derived as:
> sh_size (Size of section in byes) + sh_offset (Section file
> offst) of the elf header for text.
>
> For bfd, this value is derived as:
> 1. For PE file,
> section->size + ( section->vma - dso->text_offset)
> 2. Other cases:
> section->filepos (file position) + section->size (size of
> section)
>
> To resolve the address from a sample, perf looks at the
> DSO maps. In case of address from a kernel module, there
> were some address found to be not resolved. This was
> observed while running perf test for "Object code reading".
> Though the ip falls beteen the start address of the loaded
> module (perf map->start ) and end address ( perf map->end),
> it was unresolved.
>
> Example:
>
> 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
>
> Here, module is loaded at:
> # cat /proc/modules | grep xfs
> xfs 2228224 3 - Live 0xc008000007d00000
>
> From objdump for xfs module, text section is:
> text 0010f7bc 0000000000000000 0000000000000000 000000a0 2**4
>
> Here the offset for 0xc008000007f0142c ie 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 identify such address, which falls out of text
> section and within module end, added the new field "text_end" to
> "struct dso".
>
> Reported-by: Disha Goel <disgoel@linux.ibm.com>
> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
> Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
> Changelog:
> v2 -> v3:
> Added Reviewed-by from Adrian
>
> v1 -> v2:
> Added text_end for bfd also by updating dso__load_bfd_symbols
> as suggested by Adrian.
>
> tools/perf/util/dso.h | 1 +
> tools/perf/util/symbol-elf.c | 4 +++-
> tools/perf/util/symbol.c | 2 ++
> 3 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
> index b41c9782c754..70fe0fe69bef 100644
> --- a/tools/perf/util/dso.h
> +++ b/tools/perf/util/dso.h
> @@ -181,6 +181,7 @@ struct dso {
> u8 rel;
> struct build_id bid;
> u64 text_offset;
> + u64 text_end;
> const char *short_name;
> const char *long_name;
> u16 long_name_len;
> diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
> index 95e99c332d7e..9e7eeaf616b8 100644
> --- a/tools/perf/util/symbol-elf.c
> +++ b/tools/perf/util/symbol-elf.c
> @@ -1514,8 +1514,10 @@ dso__load_sym_internal(struct dso *dso, struct map *map, struct symsrc *syms_ss,
> }
>
> if (elf_section_by_name(runtime_ss->elf, &runtime_ss->ehdr, &tshdr,
> - ".text", NULL))
> + ".text", NULL)) {
> dso->text_offset = tshdr.sh_addr - tshdr.sh_offset;
> + dso->text_end = tshdr.sh_offset + tshdr.sh_size;
> + }
>
> if (runtime_ss->opdsec)
> opddata = elf_rawdata(runtime_ss->opdsec, NULL);
> diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> index 3f36675b7c8f..f25e4e62cf25 100644
> --- a/tools/perf/util/symbol.c
> +++ b/tools/perf/util/symbol.c
> @@ -1733,8 +1733,10 @@ int dso__load_bfd_symbols(struct dso *dso, const char *debugfile)
> /* PE symbols can only have 4 bytes, so use .text high bits */
> dso->text_offset = section->vma - (u32)section->vma;
> dso->text_offset += (u32)bfd_asymbol_value(symbols[i]);
> + dso->text_end = (section->vma - dso->text_offset) + section->size;
> } else {
> dso->text_offset = section->vma - section->filepos;
> + dso->text_end = section->filepos + section->size;
> }
> }
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH V4 2/2] tools/perf/tests: Fix object code reading to skip address that falls out of text section
2023-09-15 5:37 ` Athira Rajeev
@ 2023-09-25 10:36 ` kajoljain
-1 siblings, 0 replies; 14+ messages in thread
From: kajoljain @ 2023-09-25 10:36 UTC (permalink / raw)
To: Athira Rajeev, acme, jolsa, adrian.hunter, irogers, namhyung
Cc: linux-perf-users, linuxppc-dev, maddy, disgoel, Disha Goel
Patch looks good to me.
Reviewed-by: Kajol Jain <kjain@linux.ibm.com>
Thanks,
Kajol Jain
On 9/15/23 11:07, 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 <disgoel@linux.ibm.com>
> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
> Tested-by: Disha Goel<disgoel@linux.ibm.com>
> Reviewed-by: Adrian Hunter <adrian.hunter@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) {
> + 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);
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH V4 2/2] tools/perf/tests: Fix object code reading to skip address that falls out of text section
@ 2023-09-25 10:36 ` kajoljain
0 siblings, 0 replies; 14+ messages in thread
From: kajoljain @ 2023-09-25 10:36 UTC (permalink / raw)
To: Athira Rajeev, acme, jolsa, adrian.hunter, irogers, namhyung
Cc: linux-perf-users, Disha Goel, maddy, linuxppc-dev, disgoel
Patch looks good to me.
Reviewed-by: Kajol Jain <kjain@linux.ibm.com>
Thanks,
Kajol Jain
On 9/15/23 11:07, 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 <disgoel@linux.ibm.com>
> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
> Tested-by: Disha Goel<disgoel@linux.ibm.com>
> Reviewed-by: Adrian Hunter <adrian.hunter@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) {
> + 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);
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH V4 2/2] tools/perf/tests: Fix object code reading to skip address that falls out of text section
2023-09-15 5:37 ` Athira Rajeev
@ 2023-09-27 0:15 ` Namhyung Kim
-1 siblings, 0 replies; 14+ messages in thread
From: Namhyung Kim @ 2023-09-27 0:15 UTC (permalink / raw)
To: Athira Rajeev
Cc: acme, jolsa, adrian.hunter, irogers, linux-perf-users,
linuxppc-dev, maddy, kjain, disgoel, Disha Goel
On Thu, Sep 14, 2023 at 10:40 PM Athira Rajeev
<atrajeev@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 <disgoel@linux.ibm.com>
> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
> Tested-by: Disha Goel<disgoel@linux.ibm.com>
> Reviewed-by: Adrian Hunter <adrian.hunter@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
> + 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
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH V4 2/2] tools/perf/tests: Fix object code reading to skip address that falls out of text section
@ 2023-09-27 0:15 ` Namhyung Kim
0 siblings, 0 replies; 14+ messages in thread
From: Namhyung Kim @ 2023-09-27 0:15 UTC (permalink / raw)
To: Athira Rajeev
Cc: irogers, maddy, Disha Goel, kjain, adrian.hunter, acme,
linux-perf-users, jolsa, disgoel, linuxppc-dev
On Thu, Sep 14, 2023 at 10:40 PM Athira Rajeev
<atrajeev@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 <disgoel@linux.ibm.com>
> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
> Tested-by: Disha Goel<disgoel@linux.ibm.com>
> Reviewed-by: Adrian Hunter <adrian.hunter@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
> + 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
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH V4 2/2] tools/perf/tests: Fix object code reading to skip address that falls out of text section
2023-09-27 0:15 ` Namhyung Kim
@ 2023-09-27 14:55 ` Athira Rajeev
-1 siblings, 0 replies; 14+ messages in thread
From: Athira Rajeev @ 2023-09-27 14:55 UTC (permalink / raw)
To: Namhyung Kim
Cc: Ian Rogers, Madhavan Srinivasan, Disha Goel, Kajol Jain,
Adrian Hunter, Arnaldo Carvalho de Melo, linux-perf-users,
Jiri Olsa, Disha Goel, linuxppc-dev
> On 27-Sep-2023, at 5:45 AM, Namhyung Kim <namhyung@kernel.org> wrote:
>
> On Thu, Sep 14, 2023 at 10:40 PM Athira Rajeev
> <atrajeev@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 <disgoel@linux.ibm.com>
>> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
>> Tested-by: Disha Goel<disgoel@linux.ibm.com>
>> Reviewed-by: Adrian Hunter <adrian.hunter@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
>
>
>> + 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH V4 2/2] tools/perf/tests: Fix object code reading to skip address that falls out of text section
@ 2023-09-27 14:55 ` Athira Rajeev
0 siblings, 0 replies; 14+ messages in thread
From: Athira Rajeev @ 2023-09-27 14:55 UTC (permalink / raw)
To: Namhyung Kim
Cc: Ian Rogers, Disha Goel, Madhavan Srinivasan, Kajol Jain,
Adrian Hunter, Arnaldo Carvalho de Melo, linux-perf-users,
Jiri Olsa, Disha Goel, linuxppc-dev
> On 27-Sep-2023, at 5:45 AM, Namhyung Kim <namhyung@kernel.org> wrote:
>
> On Thu, Sep 14, 2023 at 10:40 PM Athira Rajeev
> <atrajeev@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 <disgoel@linux.ibm.com>
>> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
>> Tested-by: Disha Goel<disgoel@linux.ibm.com>
>> Reviewed-by: Adrian Hunter <adrian.hunter@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
>
>
>> + 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH V4 2/2] tools/perf/tests: Fix object code reading to skip address that falls out of text section
2023-09-27 14:55 ` Athira Rajeev
@ 2023-09-29 4:21 ` Athira Rajeev
-1 siblings, 0 replies; 14+ messages in thread
From: Athira Rajeev @ 2023-09-29 4:21 UTC (permalink / raw)
To: Namhyung Kim
Cc: Ian Rogers, Madhavan Srinivasan, Disha Goel, Kajol Jain,
Adrian Hunter, Arnaldo Carvalho de Melo, linux-perf-users,
Jiri Olsa, Disha Goel, linuxppc-dev
> On 27-Sep-2023, at 8:25 PM, Athira Rajeev <atrajeev@linux.vnet.ibm.com> wrote:
>
>
>
>> On 27-Sep-2023, at 5:45 AM, Namhyung Kim <namhyung@kernel.org> wrote:
>>
>> On Thu, Sep 14, 2023 at 10:40 PM Athira Rajeev
>> <atrajeev@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 <disgoel@linux.ibm.com>
>>> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
>>> Tested-by: Disha Goel<disgoel@linux.ibm.com>
>>> Reviewed-by: Adrian Hunter <adrian.hunter@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-atrajeev@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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH V4 2/2] tools/perf/tests: Fix object code reading to skip address that falls out of text section
@ 2023-09-29 4:21 ` Athira Rajeev
0 siblings, 0 replies; 14+ messages in thread
From: Athira Rajeev @ 2023-09-29 4:21 UTC (permalink / raw)
To: Namhyung Kim
Cc: Ian Rogers, Disha Goel, Madhavan Srinivasan, Kajol Jain,
Adrian Hunter, Arnaldo Carvalho de Melo, linux-perf-users,
Jiri Olsa, Disha Goel, linuxppc-dev
> On 27-Sep-2023, at 8:25 PM, Athira Rajeev <atrajeev@linux.vnet.ibm.com> wrote:
>
>
>
>> On 27-Sep-2023, at 5:45 AM, Namhyung Kim <namhyung@kernel.org> wrote:
>>
>> On Thu, Sep 14, 2023 at 10:40 PM Athira Rajeev
>> <atrajeev@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 <disgoel@linux.ibm.com>
>>> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
>>> Tested-by: Disha Goel<disgoel@linux.ibm.com>
>>> Reviewed-by: Adrian Hunter <adrian.hunter@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-atrajeev@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
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2023-09-29 4:22 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-09-15 5:37 [PATCH V4 1/2] tools/perf: Add text_end to "struct dso" to save .text section size Athira Rajeev
2023-09-15 5:37 ` Athira Rajeev
2023-09-15 5:37 ` [PATCH V4 2/2] tools/perf/tests: Fix object code reading to skip address that falls out of text section Athira Rajeev
2023-09-15 5:37 ` Athira Rajeev
2023-09-25 10:36 ` kajoljain
2023-09-25 10:36 ` kajoljain
2023-09-27 0:15 ` Namhyung Kim
2023-09-27 0:15 ` Namhyung Kim
2023-09-27 14:55 ` Athira Rajeev
2023-09-27 14:55 ` Athira Rajeev
2023-09-29 4:21 ` Athira Rajeev
2023-09-29 4:21 ` Athira Rajeev
2023-09-25 10:36 ` [PATCH V4 1/2] tools/perf: Add text_end to "struct dso" to save .text section size kajoljain
2023-09-25 10:36 ` kajoljain
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.