linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Disha Goel <disgoel@linux.ibm.com>
To: Athira Rajeev <atrajeev@linux.vnet.ibm.com>,
	acme@kernel.org, jolsa@kernel.org, adrian.hunter@intel.com,
	irogers@google.com, namhyung@kernel.org
Cc: linux-perf-users@vger.kernel.org, kjain@linux.ibm.com,
	maddy@linux.ibm.com, linuxppc-dev@lists.ozlabs.org,
	disgoel@linux.vnet.ibm.com
Subject: Re: [V2 2/2] tools/perf/tests: Fix object code reading to skip address that falls out of text section
Date: Thu, 14 Sep 2023 17:47:23 +0530	[thread overview]
Message-ID: <02324e34-5920-2238-0c00-f7018803939e@linux.ibm.com> (raw)
In-Reply-To: <20230907164529.36222-2-atrajeev@linux.vnet.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 3880 bytes --]

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: 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>
> ---
> 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<disgoel@linux.ibm.com>

>   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);

[-- Attachment #2: Type: text/html, Size: 4441 bytes --]

  reply	other threads:[~2023-09-14 23:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-07 16:45 [V2 1/2] tools/perf: Add text_end to "struct dso" to save .text section size Athira Rajeev
2023-09-07 16:45 ` [V2 2/2] tools/perf/tests: Fix object code reading to skip address that falls out of text section Athira Rajeev
2023-09-14 12:17   ` Disha Goel [this message]
2023-09-14 17:22     ` Athira Rajeev
2023-09-14 18:24   ` Adrian Hunter
2023-09-15  5:18     ` Athira Rajeev
2023-09-14 18:19 ` [V2 1/2] tools/perf: Add text_end to "struct dso" to save .text section size Adrian Hunter
2023-09-15  5:18   ` Athira Rajeev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=02324e34-5920-2238-0c00-f7018803939e@linux.ibm.com \
    --to=disgoel@linux.ibm.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=atrajeev@linux.vnet.ibm.com \
    --cc=disgoel@linux.vnet.ibm.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=kjain@linux.ibm.com \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=namhyung@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).