From nobody Thu Jun 5 18:12:45 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 4bCsxs0rHvz5yBhJ for ; Thu, 05 Jun 2025 18:13:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4bCsxr2Qdgz4QDf for ; Thu, 05 Jun 2025 18:12:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1032.google.com with SMTP id 98e67ed59e1d1-309fac646adso2451805a91.1 for ; Thu, 05 Jun 2025 11:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1749147177; x=1749751977; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=OqA1pDwgEWff0H7M0pjxY2KaiC5prOJt3eHj9Vjf3mE=; b=QAGl/NCWoQW8W3nLhBlgNjZCKMMfvdHEYdGfm9HlhFGQPvialZ3bvBV8FwraIfENxe QPKecWkGJadEGloB1+uSugppJRtG9hxZJZIf8kv0PeQdTJnQRY+jET66uc5broA69SfH uwtJkwmkIhTVC0hSAQJKfwxI0hd3CVsHBIDIo2z0lrTfB9AsAY6+Cnt3qDRwWidstEYc HjTu70v9s8j/KVlaYwIWwHzIEwVdtgXKzLnw4oJaDZYcdzjdEeCuwBH0zJ+3ed/wLIFB 6quR53YcDroa2irc5BphP29f3QOmu6IDd0xP0O+TcE/m9KRHc0wAlUnRk0eLcFPdSWXE SveA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749147177; x=1749751977; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=OqA1pDwgEWff0H7M0pjxY2KaiC5prOJt3eHj9Vjf3mE=; b=jxvXLee0w8MUT1NVCAXX5R3rh1U3AKTJ/lDliLfSTjS7uDGhZrd//ziQGvq6IHAye2 S2GNZw8i/YgTX5fjaJMPH4HkODju8mccj1uBIzkqpz9T/PGfFBrxqzieq+LkXc1a9GOt 7jIzJNecwE47w7nwHrKcH6HmuFb1ToImJt67ZJw1GKllW5tGeZZhb7wMTMOruHN5BuRH pF0oo5jJ2zV+QxL7Hxbs7TqmqO43OfXubCN5HXTeh7aOyGn6oMFMIeymPJvPLzOW/AGL VTyNXwDCuXbDu9KG4GjMpyLhM8Q2GrmGwF9h6va9I8DbcMjMCmIL9u5FsOZ2hfgujVEQ LOaQ== X-Forwarded-Encrypted: i=1; AJvYcCU4q1o5zYOseOR7RexOUfTDXlQ+Y9qHDJ4La1YzSvmDWVa7/YLFtHNN6+YoXPt3/kxTIncmTAqx+Zg9GAL2IGBjRkeqMQ==@freebsd.org X-Gm-Message-State: AOJu0Yy9AUpLgpGvGdXlfdEjjuBIu8EOzeLF2nsl6PkL/cbjz6SjHBhk U3VHhyfUv0Svls/NjuBZl/1kCpfoUlq6Xej7WatlTjAMbXrivKhY0eIFjLvUeBGLVVXAh//W/dn HY2NDITIQXOAOslNFLndRJK1lS64Q2tn/w2nESi+rZQ== X-Gm-Gg: ASbGnctgXAfEln4Hw6if1e0hI1Wmho9ScFcCflOBEKIXBOIWFgOAiCZZOsai2hdBbI3 DTTLwDTN4hB/XZRYu77FCaPZVcKnrZWvd6oD3576AvwTkRPTnKnAcU6BoRXL1NIg4+TiYCjzaw1 ZmKKT+TGiH41MutDWtJ6H339+FNOrqThH60AhYiFcnZ0qij7eRJug/NQ== X-Google-Smtp-Source: AGHT+IHpz8gL5WfFV/3GlrNnmSJfH7N/xOqrKJP4SDlnGTOzCO3Z2gTMAh7a+qAnaSBKNWoMozXLkAlU/I/5W+fzGCY= X-Received: by 2002:a17:90b:48d0:b0:312:e751:8213 with SMTP id 98e67ed59e1d1-31349fb548cmr212263a91.13.1749147177457; Thu, 05 Jun 2025 11:12:57 -0700 (PDT) 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 References: <202506040151.5541pESm016476@gitrepo.freebsd.org> <02ed6d30-b22a-456d-96e2-7f5b235766fd@FreeBSD.org> <0b4a1945-8f75-4f57-9a57-5bd0c10a7af1@FreeBSD.org> <701efeb3-3a7e-42fe-ba18-eaf1862c7a3f@FreeBSD.org> In-Reply-To: <701efeb3-3a7e-42fe-ba18-eaf1862c7a3f@FreeBSD.org> From: Warner Losh Date: Thu, 5 Jun 2025 11:12:45 -0700 X-Gm-Features: AX0GCFsPT5Pm95U3y3l_pis9fx9HAtoOsjge7x-i0CQ9FBggtZ-NtlqyVaNyDpc Message-ID: Subject: Re: git: 969f6380eb66 - main - kdump: nicer printing of kill(2) PID argument To: Kyle Evans Cc: John Baldwin , Gleb Smirnoff , markj@freebsd.org, src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4bCsxr2Qdgz4QDf X-Spamd-Bar: ---- 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)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] On Thu, Jun 5, 2025 at 10:59=E2=80=AFAM Kyle Evans wro= te: > > On 6/5/25 11:54, Warner Losh wrote: > > On Thu, Jun 5, 2025 at 6:14=E2=80=AFAM John Baldwin w= rote: > >> > >> 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=3D969f6380eb66f809ee= d3e5c38b6021824a4cc2bf > >>>> 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 e= yeball 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 f= or > >>>> 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 da= y > >>> 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 a= bout > >> 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 s= o > >> 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 makesysca= lls.lua > >> as many of the "types" truss uses are synthetic types that aren't visi= ble > >> 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 inst= ead > >> be closer to truss where you instead just iterate over types. It woul= d > >> also mean only having to update a single table in libsysdecode when ad= ding > >> a new system call to add both truss and kdump support. Only when a ne= w > >> 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. That's a great idea. I've not had the time to write it up with sufficient detail for a gSOC student to want to do it... There's half a dozen different projects we could do to improve somebody's quality of life and implementation... Warner