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.