From nobody Thu Jun 5 13:14:31 2025 X-Original-To: dev-commits-src-main@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 4bClKN5PKgz5xp4N; Thu, 05 Jun 2025 13:14:32 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4bClKN4Vx6z3nCZ; Thu, 05 Jun 2025 13:14:32 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1749129272; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gq3+M5USFqbs8/4uxAdqUvK4474poCa30QcWvToPnFI=; b=n3rUPfsNnteRJAVFw4TaH62QCyu3Ma5D9xQVrq9xvQYRRpSfnOtolBU4ZP5H8fHpaiH8cy v30XG7H3Mn/SJf4219Dzw3LC4Qwc7v4kkhHi3IVY2+QWHYAdmI3dh2X/KbcAa7bUYSlMn1 NJL1VQawUx/x9IVu7Yr/W9gLD2ThNwjgHvy2kuitVVNEBxmKywEKtB9G7+j+p78Ttplq+P qLYm4PDeS8SrfBEUf7VPYfZP+6bORapHWIs5n1+q1niGEwTsVKjAypXNZwzriYJt1zdnTJ 89kO/+tQTcRrU8UdHfSG/pnuEHS7r8+YVA9Q43vIWDe2Zr7Vz9WeCThBJWB1bw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1749129272; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gq3+M5USFqbs8/4uxAdqUvK4474poCa30QcWvToPnFI=; b=dts89Qq3fvvjxc6aJ/IhEEfySeegru1cuPtfiPisikCFppgzGIohiB7kg+GdJXXTCEpuVr Dfm/yWnfWNejZALboT7kRYQaLLXwKD25yX0zUrh/aHCmcCJxf2rfXhmU4AEukIsPpln8Qm xCQbhRQgXLYfziETldDjKCBXDWNrEabv9yMo2OPFPN3+shQt37KH4tE+6VrrLHDcj/5ueY PsHXFfEDinsydfkLLphqltrCNEA5lho3UiB0hKRz2g2U9mtIc/2YXbwAmUL7879rudP4A4 88ShO1HsBZB9+UAiJrbiQ1m0ooFgd0+Ipqaa8NPGTadCRS+JqruVxKUpyKvEfQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1749129272; a=rsa-sha256; cv=none; b=CW4+qLn8mY6r37foEwtMiCjJthCJe+RhlUGaTGq2AD7Cp45UFJbeVg1B/uwvMtFCqhfsac VX9HIcZXiGMnfokrNHndfX3clkIARIjHsIQqwPQwkUzGKcCFgpkQ34uyrXEzzBhS1weG1V 6fuuPOuID12zwbGRbQvay18RwaSvyKQGOkeBvS0JZVPSWJG8t/kB0q10dbud7gFs24VcQU S2m6gYRv7QZosc/pZFPPsZ4PUy9BIQNatc1T7i9S96pxGRPJJtd/SZ6nZKVn9UfXw2SDqq YbWXyfm50MpQUw/PqqnasmWFJBpfm7g8nINzhKvFMOFXQDji9INtd/wNrauEaQ== Received: from [IPV6:2601:5c0:4200:b830:a1dc:a233:e9a8:3ed1] (unknown [IPv6:2601:5c0:4200:b830:a1dc:a233:e9a8:3ed1]) (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 did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4bClKN1ffyz14cy; Thu, 05 Jun 2025 13:14:32 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <0b4a1945-8f75-4f57-9a57-5bd0c10a7af1@FreeBSD.org> Date: Thu, 5 Jun 2025 09:14:31 -0400 List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: git: 969f6380eb66 - main - kdump: nicer printing of kill(2) PID argument Content-Language: en-US To: Kyle Evans , Gleb Smirnoff , markj@freebsd.org Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org References: <202506040151.5541pESm016476@gitrepo.freebsd.org> <02ed6d30-b22a-456d-96e2-7f5b235766fd@FreeBSD.org> From: John Baldwin In-Reply-To: <02ed6d30-b22a-456d-96e2-7f5b235766fd@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 6/4/25 19:03, Kyle Evans wrote: > On 6/4/25 17:55, Gleb Smirnoff wrote: >> On Wed, Jun 04, 2025 at 01:51:14AM +0000, Kyle Evans wrote: >> K> The branch main has been updated by kevans: >> K> >> K> URL: https://cgit.FreeBSD.org/src/commit/?id=969f6380eb66f809eed3e5c38b6021824a4cc2bf >> K> >> K> commit 969f6380eb66f809eed3e5c38b6021824a4cc2bf >> K> Author: Kyle Evans >> K> AuthorDate: 2025-06-04 01:51:06 +0000 >> K> Commit: Kyle Evans >> K> CommitDate: 2025-06-04 01:51:06 +0000 >> K> >> K> kdump: nicer printing of kill(2) PID argument >> K> >> K> Similar to wait*(), kill(2) operates on a pid that currently gets output >> K> as hex. Output it in decimal to make it a little easier to eyeball the >> K> pid we're signalling. >> K> >> K> Reviewed by: markj >> K> Differential Revision: https://reviews.freebsd.org/D50508 >> >> I didn't review if PIDs are always printed as decimals or not, but for >> the file descriptors it is a mix of hex and decimals. :( Usually I go >> with a sed script over kdump output to make it consistent. >> > > To be fair, I'd like to fix that, too- I noticed close() the other day > for fd > 0, but paused when I: > > 1.) couldn't tell where we even output close args close is probably handled by the default case where where all of the arguments are just output as hex values. Note that for kdump, most syscalls fall into this case including syscalls with pointer arguments. You'd probably be a bit sad with 64-bit pointers printed as decimal for many system calls. truss is different as truss stores some rudimentary type information about system call arguments and then defaults to printing certain types like file descriptors and ids as decimal. truss also prints NULL for null pointers IIRC. A useful project perhaps would be to move the table describing system call argument types out of syscalls.c in truss and into libsysdecode so that kdump could also reuse it. Probably the API you would want is something that returns an individual `struct syscall_decode` given (ABI, number) input arguments. I don't think you can generate this table automatically from makesyscalls.lua as many of the "types" truss uses are synthetic types that aren't visible in C, e.g. "OpenFlags" meaning O_* flags passed to open(2). This would allow kdump's hand-written per-syscall-number rules to instead be closer to truss where you instead just iterate over types. It would also mean only having to update a single table in libsysdecode when adding a new system call to add both truss and kdump support. Only when a new argument type is added would one have to actually touch truss or kdump directly. -- John Baldwin