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
>
next prev parent 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 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.