From nobody Thu Jun 5 17:59:14 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 4bCsdw0D6Jz5y9cD; Thu, 05 Jun 2025 17:59:16 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4bCsdv6bJfz4GLV; Thu, 05 Jun 2025 17:59:15 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1749146355; 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=Y1qzbT546QYMtfRvmBpG+mE/3WMji0RthNbMdJUHAdg=; b=M/M6HZB6Bdj1M4F1a+vl6MdjWa3PSubRs+K5ZX8X2i8rH+ewGOwHcQhpZxCeVhBiDfVDdE SE7s+kgdfW+ZFKbEoFi6h3OfWI3ngWx5oq65XWU1owznBLgraWSx2jEaPkZkmCwTM2dOUL W1+7+ucfLB5v8s3bTaXwxwWenAB15rcByFfSc26C1df1iA+Btt/0REO+0Bw2WG7xFhPrXn kMyJcUmsdyV1kcQ0GBo62ukm90O6Y6SmySSpZkZyh5EQ/WISIc6La990sB4Mtqv58NxoPc ourB01OXbJC1a3iW+hFcjkNQ4OMAQHcQ656LP67vxHK2l5bHN0h+oC1vCVTYEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1749146355; 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=Y1qzbT546QYMtfRvmBpG+mE/3WMji0RthNbMdJUHAdg=; b=URAVNUEBgYPKslgnBG07g6sw6N5wGR4obcn4d9awPXQ5wrKswlhk38jQvnDF8TaP601BCs suHWZiFoLhz/QBLssRoDt4uWhYeFj8tNNkDHmdJukgUFPKM6L/vHcAqjJx/F8CSJx745sy 89PinyM1RAvQ4zk4v2N2VDK5jUygmUhAT9P3y3MukP5kWhwM4ZBh3V7a6QVIPXCqFMoA5E UUtN4dHr8doSXRqKYRiA3wCLJgwS+co1njPsiRr+qOHBJgUzQ7VWyDvKSFWAyNsOashjLh wc+mystkO+0OoWpD+heNurdFo02xnFrS7/PjEc3v8BpgwbEQXXtplqSfWJwbyw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1749146355; a=rsa-sha256; cv=none; b=BLhW3x0YcF26rqUZl+BhqFUBX1xLWttPnIpOtyXTCm02HA4ngSmrCD0H9GTk1m2rVrleus gd+jvG71tO9bDBg/sJnasZs6jFstSUWfjZv79yP389GIKRTIjE+3w9SHlhTP64FnJvS0gO vl1HuNbpD62O/fIvNedBo5Hrj3HKfcTDge3CWnB6W4mbL1n9asTK5M3t0AoAs0yJWSCkff kwjRRFDuoSCJgl+dYeyYduQPspIqYov3cY8q/plvzZFQ/P6sepFSsV36VveApwUNiPpL/W V41q4EcCwhVI5euB1WUvv+XZuFMHJpX55hy8OICAzbqiKwltaOfPCjZIyVOU2g== Received: from [10.9.4.95] (unknown [209.182.120.176]) (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: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4bCsdv1L9dz196s; Thu, 05 Jun 2025 17:59:15 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: <701efeb3-3a7e-42fe-ba18-eaf1862c7a3f@FreeBSD.org> Date: Thu, 5 Jun 2025 12:59:14 -0500 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 To: Warner Losh , John Baldwin Cc: Gleb Smirnoff , markj@freebsd.org, 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> <0b4a1945-8f75-4f57-9a57-5bd0c10a7af1@FreeBSD.org> Content-Language: en-US From: Kyle Evans In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 6/5/25 11:54, Warner Losh wrote: > On Thu, Jun 5, 2025 at 6:14 AM John Baldwin wrote: >> >> 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. > > Yes. All this generation is why we did the lua project to make the > master system call table parsing into a library. We need it also for > qemu-bsd-user long-term: writing new system calls by hand is a pain > and error-prone. > >> 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). > > I think that we should, in the fullness of time, flag these so we can > do that. If we do add additional notations, we can not only have > better truss/trace output, as well as being able to generate the right > flag translations for running FreeBSD binaries on Linux (which people > are doing by hand right now...). > >> 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. > > I'd love for this to be generated as well... It was certainly one of > the use cases that we had in mind for the GSOC project that did this. > If we don't currently have a GSoC project idea around the above thoughts about truss -> libsysdecode and how we might be able to leverage makesyscalls and/or other annotations for it, maybe that'd be good to fish for in the 2026 program. I'm afraid I don't really have time for more than the sniping of random cases that make my life a tiny bit harder for the foreseeable future. Thanks, Kyle Evans