public inbox for dtrace@lists.linux.dev
 help / color / mirror / Atom feed
From: Kris Van Hees <kris.van.hees@oracle.com>
To: eugene.loh@oracle.com
Cc: dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [PATCH] No uprobes on ARM autiasp instructions
Date: Mon, 11 Aug 2025 13:54:09 -0400	[thread overview]
Message-ID: <aJouQe8qUJSIPKD7@oracle.com> (raw)
In-Reply-To: <20250610211042.20522-1-eugene.loh@oracle.com>

On Tue, Jun 10, 2025 at 05:10:42PM -0400, eugene.loh@oracle.com wrote:
> From: Eugene Loh <eugene.loh@oracle.com>
> 
> New compilers emit autiasp instructions much more liberally.
> A test like test/unittest/pid/tst.entry_off0.sh, which tries
> to put a probe on each instruction, may fail.
> 
> Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
> ---
>  libdtrace/dt_pid.c | 23 +++++++++++++++++------
>  1 file changed, 17 insertions(+), 6 deletions(-)
> 
> diff --git a/libdtrace/dt_pid.c b/libdtrace/dt_pid.c
> index e2d4e540d..833e9b647 100644
> --- a/libdtrace/dt_pid.c
> +++ b/libdtrace/dt_pid.c
> @@ -279,12 +279,17 @@ dt_pid_per_sym(dt_pid_probe_t *pp, const GElf_Sym *symp, const char *func)
>  
>  		nmatches++;
>  	} else if (glob) {
> -#if defined(__amd64)
>  		/*
> -		 * We need to step through the instructions to find their
> -		 * offsets.  This is difficult on x86, which has variable
> -		 * instruction lengths.  We invoke the disassembler in
> -		 * libopcodes.
> +		 * We need the instructions for two reasons:
> +		 * = On x86, instructions have varying lengths.  So,
> +		 *   to step through the instructions, we need to
> +		 *   disassemble them to know what they are.
> +		 *   We invoke the disassembler in libopcodes.
> +		 *   (On ARM, we step through 4 bytes at a time.)
> +		 * = On both x86 and arm, we want to skip certain
> +		 *   instructions.  So, again, we need to know what they are.
> +		 */
> +		/*
>  		 *
>  		 * We look for the Elf pointer.  It is already stored in
>  		 * file_elf in file_info_t, but getting it back over here
> @@ -298,7 +303,6 @@ dt_pid_per_sym(dt_pid_probe_t *pp, const GElf_Sym *symp, const char *func)
>  		GElf_Shdr shdr;
>  		Elf_Data *data;
>  		size_t shstrndx, off;
> -		disassembler_ftype disasm;
>  
>  		/* Set things up. */
>  		fd = open(pp->dpp_fname, O_RDONLY);
> @@ -344,12 +348,14 @@ dt_pid_per_sym(dt_pid_probe_t *pp, const GElf_Sym *symp, const char *func)
>  		/* Get the instructions. */
>  		data = elf_getdata(scn, NULL);
>  
> +#if defined(__amd64)
>  		/*
>  		 * "Disassemble" instructions just to get the offsets.
>  		 *
>  		 * Unfortunately, libopcodes's disassembler() has a different
>  		 * interface in binutils versions before 2.29.
>  		 */
> +		disassembler_ftype disasm;
>  #if defined(HAVE_DIS1) == defined(HAVE_DIS4)
>  #error expect disassembler() to have 1 or else 4 arguments
>  #endif
> @@ -390,6 +396,11 @@ dt_pid_per_sym(dt_pid_probe_t *pp, const GElf_Sym *symp, const char *func)
>  			/* Newer kernels do not allow uprobes on "hlt" instructions. */
>  			if ((unsigned int)disasm_info.buffer[off] == 0xf4)
>  				continue;
> +#else
> +			/* On ARM, we cannot place uprobes on "autiasp" instructions. */
> +			if (*((unsigned int *)(data->d_buf + (sym.st_value + off - shdr.sh_addr)))
> +			    == 0xd50323bf)

Are there symbolic names we can use here?  From an include file concerning
opcodes or (worst case) define one ourselves.  From the comment, I can assume
that the 32-bit hex value you give must be that instruction.  But is it an
actual 4-byte instruction without any values taht can be set for different
uses, etc?  Perhaps a define and a comment explaining the value might be
useful here.

And perhaps do the same for the 'hlt' x86 instruction mentioned above it?

> +				continue;
>  #endif
>  
>  			snprintf(offstr, sizeof(offstr), "%lx", off);
> -- 
> 2.43.5
> 

  reply	other threads:[~2025-08-11 17:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-10 21:10 [PATCH] No uprobes on ARM autiasp instructions eugene.loh
2025-08-11 17:54 ` Kris Van Hees [this message]
2025-08-11 20:52   ` Eugene Loh
2025-08-11 22:13     ` Kris Van Hees
2025-08-18 16:30       ` Kris Van Hees

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=aJouQe8qUJSIPKD7@oracle.com \
    --to=kris.van.hees@oracle.com \
    --cc=dtrace-devel@oss.oracle.com \
    --cc=dtrace@lists.linux.dev \
    --cc=eugene.loh@oracle.com \
    /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