From nobody Mon Apr 10 18:42:18 2023 X-Original-To: freebsd-dtrace@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 4PwHs25CGdz44fb2 for ; Mon, 10 Apr 2023 18:42:30 +0000 (UTC) (envelope-from christos@freebsd.org) Received: from margiolis.net (mail.margiolis.net [95.179.159.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PwHs10ZMFz4Dl7; Mon, 10 Apr 2023 18:42:29 +0000 (UTC) (envelope-from christos@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=margiolis.net header.s=default header.b=UwSPbN3x; spf=softfail (mx1.freebsd.org: 95.179.159.8 is neither permitted nor denied by domain of christos@freebsd.org) smtp.mailfrom=christos@freebsd.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=default; bh=PZLEAuM6LJhB hqK8tFdjE/PKpN8E0Ec3wCKQJ3/ADB0=; h=subject:cc:to:from:date; d=margiolis.net; b=UwSPbN3xLtQIA61ygPGcDdIj2B/szcwkdrt3HBDaVXvUGo4K4dz kk59jZqwXgR3hm6f9NMSPPQWF9ygGF7GGQCIugFZEDAQwjFTDc3iKGnW0T1VBOZeIEkolX NGy+TjwUIFMReNq14O2Xfdw57zT97grcynYNkaoSMqbGXcV7Fw= Received: from pleb (ppp-94-66-59-63.home.otenet.gr [94.66.59.63]) by margiolis.net (OpenSMTPD) with ESMTPSA id 1757ed34 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Mon, 10 Apr 2023 18:42:19 +0000 (UTC) Date: Mon, 10 Apr 2023 21:42:18 +0300 From: Christos Margiolis To: status-updates@freebsdfoundation.org Cc: freebsd-dtrace@freebsd.org, markj@freebsd.org, jrm@freebsd.org, mhorne@freebsd.org Subject: [Development report #7] Improve the kinst DTrace provider Message-ID: <20230410184218.i6gez6eusmxz2zli@pleb> List-Id: A discussion list for developers working on DTrace in FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-dtrace List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-dtrace@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spamd-Result: default: False [-2.80 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[margiolis.net:s=default]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-dtrace@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[margiolis.net:+]; ASN(0.00)[asn:20473, ipnet:95.179.144.0/20, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[christos]; ARC_NA(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TO_DN_NONE(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4PwHs10ZMFz4Dl7 X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N The past few days I've been working on the forthcoming RISC-V port of kinst. Tracing of individual instructions in kinst so far (i.e in amd64) works by using a trampoline which contains the actual instruction, followed by an unconditional jump back to the next instruction so that we can resume execution. In RISC-V however this turns out to not really be possible, because we cannot encode large displacement values in a single instruction in order to form a far jump [1]. To compensate for this, the RISC-V trampoline contains the instruction, followed by an EBREAK (breakpoint) instruction. kinst_invop() is able to detect if the breakpoint was triggered by the trampoline, where in this case, it manually sets the program counter to the next instruction, instead of using a jump. So far only instructions that do not address memory can be traced without problems. Since the displacement issue I mentioned above re-appears here as well, instructions that need modification [2] will most likely not use the trampoline at all, and be emulated in software instead, like we do in amd64 kinst for call instructions. [1] Trampoline addresses are located above the kernel base address, which can be several MBs away from the instruction we are tracing. [2] Some instructions need modification, that is, for instructions that use relative addressing (e.g PC-relative ones), we have to recalculate the displacement to be relative to the trampoline address. From nobody Fri Apr 28 14:11:41 2023 X-Original-To: freebsd-dtrace@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 4Q7F0S6GSJz48Wqd for ; Fri, 28 Apr 2023 14:11:52 +0000 (UTC) (envelope-from christos@freebsd.org) Received: from margiolis.net (mail.margiolis.net [95.179.159.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q7F0R61Glz3wtS; Fri, 28 Apr 2023 14:11:51 +0000 (UTC) (envelope-from christos@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=margiolis.net header.s=default header.b=KbwYFzN4; spf=softfail (mx1.freebsd.org: 95.179.159.8 is neither permitted nor denied by domain of christos@freebsd.org) smtp.mailfrom=christos@freebsd.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=default; bh=IGOZ7aGzKDIg PWTkyphsAltA9aG3YeecGurM2X8MlyE=; h=subject:cc:to:from:date; d=margiolis.net; b=KbwYFzN4KBZQMCoLUMSnxaofq8ZxuREOY+N+vdU7NNWqyP5v1h+ UO+UyZyynGG0rqKOMSl3kETCuecDWcyYzGnxKe9y9xcxX+Ubr/c0FEsnJu5n1WPJnQqJB6 fRG6Xmsz2/czADB+t0AHeb+JJlOTyxYSKto2SRE9ypfu/H4Dtg= Received: from pleb (ppp-94-66-59-63.home.otenet.gr [94.66.59.63]) by margiolis.net (OpenSMTPD) with ESMTPSA id 8b671696 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Fri, 28 Apr 2023 14:11:42 +0000 (UTC) Date: Fri, 28 Apr 2023 17:11:41 +0300 From: Christos Margiolis To: status-updates@freebsdfoundation.org Cc: freebsd-dtrace@freebsd.org, markj@freebsd.org, jrm@freebsd.org Subject: [Development report #8] Improve the kinst DTrace provider Message-ID: <20230428141141.y74jra2tfvirwcdd@pleb> List-Id: A discussion list for developers working on DTrace in FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-dtrace List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-dtrace@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spamd-Result: default: False [-2.78 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.980]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[margiolis.net:s=default]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-dtrace@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[margiolis.net:+]; ASN(0.00)[asn:20473, ipnet:95.179.144.0/20, country:US]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[christos]; ARC_NA(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4Q7F0R61Glz3wtS X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N A brief overview of the things I've been working on since the last update: * The RISC-V port of kinst was crashing if we tried to access the address pointed to by `frame->tf_tp`. This was a result of TP being unitialized if accessed by DTrace in probe context. I wrote a patch [1] which saves the thread pointer in both userland and kernel mode exceptions. * Emulated all PC-relative RV64[IC] instructions. * Fixed various bugs in both the emulation and the double breakpoint mechanism. There is however still an unsolved bug which hangs the system if we try to trace a very specific block of instructions in vm_fault() (instructions 4436 to 4450). Once this is fixed, the RISC-V port will most likely be complete. * Added register bindings to RISC-V DTrace [2]. * Exposed dtrace_instr_size() to userland and implemented it for RISC-V [3]. Other architectures are meant to also implement this function as well and use it across DTrace code. * In report #5 I mentioned that cpu_switch() was safe to trace. It turns out it's not. * Submitted and working on various as-of-now open PRs related to DTrace and kinst. [1] https://cgit.freebsd.org/src/commit/?id=d95fbf4e1a12565908b04b442263fe60c9e890b4 [2] https://cgit.freebsd.org/src/commit/?id=1fef7abdc76bd6f0c93775bd0c1b62b523abd20d [3] https://cgit.freebsd.org/src/commit/?id=080e56a6c98c7e7a241a4260d4c19d3cad5b22af