From nobody Tue Nov 01 13:45:12 2022 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N1rqw5GLzz4gM1R; Tue, 1 Nov 2022 13:45:16 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N1rqw4kw2z3fXx; Tue, 1 Nov 2022 13:45:16 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk1-x72d.google.com with SMTP id z30so9512080qkz.13; Tue, 01 Nov 2022 06:45:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=F1jhBuk5nRTL1uM+Db35xhWIjlAhPmhIQgr0cHdT9Zg=; b=BnWrcfWA1nhiDyHUD/kGgljlJKHXZP5zMPRYc9MYGbe7rWdzGGUl6dK2h1PO3zYzAl lCbmQR8nV/+RjYJXwVucMj9Eem3gsor650L+b0weAY9IMmc2/S1yWjuSIV22OBuRn7W4 J6EkLRccULzMSqi57cr14recMD2RLP55KL5IeW9KApZQ53PBJOnN5OFODkV2PgYYcTtG S5yPhAA5viirgieywqXrR+dRQ+qOaJcvdurxAXSiTHwtR44VzrQkS35Pv7bVSR0pgNqD P64pNx64YUTC+XK3IZ66HydweQymaoKBxBnlZA35aDOIJLWz44cW2YpUOf0gxZ+QsSrr ZTXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=F1jhBuk5nRTL1uM+Db35xhWIjlAhPmhIQgr0cHdT9Zg=; b=zvaReD9QAM1JAk/GT24lKFFdR4dY24Md8/9CI3Cqiu3V+aBENrwa2LnZQemNdPfua/ irfyC/3LdRphlXjJyR7pJ38JYriFuVNCvbFxi4C0WaQdN5C9TBR4uXSl6niqEm+spoG0 vnxCqtmiuX+k2J9mTPuZRdUxFDarAEbSsOpCljnWdoGE0aY+eMqwcQiNdaRUkuclAgti ixYgM1+pkzSUSypSD8lDauV/691MpAvuYpfeYb+BTbIFu3shlI9Od+D4RrN89i2IM4kw pTyJwUYsYVbTVEFJc2AwbSjeczjwSkQA9s9QhxKGCMtoYyyqkmz51zKKQ9TT0h/BGzi+ sq1Q== X-Gm-Message-State: ACrzQf2sZGygoKIuSVLlV8Lzf7N4ogcqxbgQwJ9F/hC+5/zikAuWzSIm YX/BYD8aQHxVjglDZ71BYkKqu18d34EBbA== X-Google-Smtp-Source: AMsMyM4EDtZDDrKYgJq7sNggSDOBtPhZJ0Qhl7KnPBy6Z36H3PyjQ5lCIsOVD8WmM+EWac4UZvrJ5Q== X-Received: by 2002:a05:620a:1430:b0:6fa:b78:7e07 with SMTP id k16-20020a05620a143000b006fa0b787e07mr13051637qkj.120.1667310315375; Tue, 01 Nov 2022 06:45:15 -0700 (PDT) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id g12-20020a05620a13cc00b006ecf030ef15sm6468878qkl.65.2022.11.01.06.45.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Nov 2022 06:45:14 -0700 (PDT) Date: Tue, 1 Nov 2022 09:45:12 -0400 From: Mark Johnston To: Konstantin Belousov Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 0e69c959150c - main - dtrace: Fix up %rip for invop probes on x86 Message-ID: References: <202210312312.29VNCH6A012822@gitrepo.freebsd.org> List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Rspamd-Queue-Id: 4N1rqw4kw2z3fXx X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Nov 01, 2022 at 03:36:20PM +0200, Konstantin Belousov wrote: > On Mon, Oct 31, 2022 at 11:12:17PM +0000, Mark Johnston wrote: > > The branch main has been updated by markj: > > > > URL: https://cgit.FreeBSD.org/src/commit/?id=0e69c959150c0ba38459e9121158016ee34b0d92 > > > > commit 0e69c959150c0ba38459e9121158016ee34b0d92 > > Author: Mark Johnston > > AuthorDate: 2022-10-31 23:11:36 +0000 > > Commit: Mark Johnston > > CommitDate: 2022-10-31 23:11:36 +0000 > > > > dtrace: Fix up %rip for invop probes on x86 > > > > When a breakpoint exception is raised, the saved value of %rip points to > > the instruction following the breakpoint. However, when fetching the > > value of %rip using regs[], it's more natural to provide the address of > > the breakpoint itself, so modify the kinst and fbt providers accordingly. > > > > Reported by: khng > > Reviewed by: christos, khng > > MFC after: 2 months > > Differential Revision: https://reviews.freebsd.org/D37218 > > --- > > sys/cddl/dev/fbt/x86/fbt_isa.c | 8 ++++++++ > > sys/cddl/dev/kinst/amd64/kinst_isa.c | 8 +++++++- > > 2 files changed, 15 insertions(+), 1 deletion(-) > > > > diff --git a/sys/cddl/dev/fbt/x86/fbt_isa.c b/sys/cddl/dev/fbt/x86/fbt_isa.c > > index 05ec87ab437f..b05ae4cb2c44 100644 > > --- a/sys/cddl/dev/fbt/x86/fbt_isa.c > > +++ b/sys/cddl/dev/fbt/x86/fbt_isa.c > > @@ -84,6 +84,12 @@ fbt_invop(uintptr_t addr, struct trapframe *frame, uintptr_t scratch __unused) > > if ((uintptr_t)fbt->fbtp_patchpoint != addr) > > continue; > > fbtrval = fbt->fbtp_rval; > > + > > + /* > > + * Report the address of the breakpoint for the benefit > > + * of consumers fetching register values with regs[]. > > + */ > > + frame->tf_rip--; > > for (; fbt != NULL; fbt = fbt->fbtp_tracenext) { > > ASSERT(fbt->fbtp_rval == fbtrval); > > if (fbt->fbtp_roffset == 0) { > > @@ -143,6 +149,8 @@ fbt_invop(uintptr_t addr, struct trapframe *frame, uintptr_t scratch __unused) > > cpu->cpu_dtrace_caller = 0; > > } > > } > > + /* Advance to the instruction following the breakpoint. */ > > + frame->tf_rip++; > > return (fbtrval); > > } > > > > diff --git a/sys/cddl/dev/kinst/amd64/kinst_isa.c b/sys/cddl/dev/kinst/amd64/kinst_isa.c > > index 6d8d5d521617..e47cfbbf4d4e 100644 > > --- a/sys/cddl/dev/kinst/amd64/kinst_isa.c > > +++ b/sys/cddl/dev/kinst/amd64/kinst_isa.c > > @@ -139,6 +139,12 @@ kinst_invop(uintptr_t addr, struct trapframe *frame, uintptr_t scratch) > > if (kp == NULL) > > return (0); > > > > + /* > > + * Report the address of the breakpoint for the benefit of consumers > > + * fetching register values with regs[]. > > + */ > > + frame->tf_rip--; > > + > > DTRACE_CPUFLAG_SET(CPU_DTRACE_NOFAULT); > > cpu->cpu_dtrace_caller = stack[0]; > > DTRACE_CPUFLAG_CLEAR(CPU_DTRACE_NOFAULT | CPU_DTRACE_BADADDR); > > @@ -162,7 +168,7 @@ kinst_invop(uintptr_t addr, struct trapframe *frame, uintptr_t scratch) > > > > if (kpmd->reg1 == -1 && kpmd->reg2 == -1) { > > /* rip-relative */ > > - rval = frame->tf_rip - 1 + kpmd->instlen; > > + rval = frame->tf_rip + kpmd->instlen; > > } else { > > /* indirect */ > > rval = kinst_regval(frame, kpmd->reg1) + > > I am somewhat curious. Is the breakpoint used there means INT3? Right. > If yes, then %eip++ most likely points into the middle of the overwritten > multibyte instruction. In this case it does not: on x86, FBT only overwrites single-byte instructions currently, "push %rbp" and "ret", so we can assume that %eip++ points to next instruction (and for "ret" %rip will be overridden later anyway). This could change, but it would require other changes to fbt_invop(). kinst can probe multi-byte instructions, but there we do not increment the instruction pointer this way. After the probe fires and kinst_invop() is finished its work, %rip will point to either 1) an instruction trampoline containing a copy of the probed instruction (possibly modified if it is %rip-relative) followed by a jmp to the instruction following the probed instruction, or 2) the computed branch target for "call" instructions.