From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS20473 45.76.80.0/20 X-Spam-Status: No, score=-3.3 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 Received: from mail.smrk.net (mail.smrk.net [45.76.87.244]) (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) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 588CF1F406 for ; Mon, 27 Nov 2023 11:20:04 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=smrk.net header.i=@smrk.net header.a=rsa-sha256 header.s=20221002 header.b=USRYPIkr; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smrk.net; s=20221002; t=1701084002; 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=JrgN32VbyzqF6W44fiK7DIaZI2Omh5W6QjT052fqVZI=; b=USRYPIkrTKVGsFd4HlL+zAbquJFpUbvLE2+aS5E04cYfBDEW2FlhmqpSZzQvvaIcb+gUob e3gpcACqijP2Xkum0efUCNfWPgBAiNbBXJVWhPFji/XCVYhZp5ajQBZoOhyGAwlXmibk1o dMST9yYj79i8Wc8UKDvIa2tkkSdGOxEsyEGdCW2aPgwsuQlL++X9gEtn52mSNhkGKDRA1u o0XSqE2UzsrDfW9d8zIGNF6/0S95OKcKI6giJmoq2GV+YkD13XaqdI8Qi9PKmehMu3ady0 IQDtVQZJkQdVmFf/v1dHopYaMKnUifQPQia8itFzValLJPpfMAX1SmHkO+Ri2A== Received: from localhost ( [192.168.5.2]) by smrk (OpenSMTPD) with ESMTPSA id ffc5e694 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 27 Nov 2023 12:20:02 +0100 (CET) From: =?utf-8?B?xaB0xJtww6FuIE7Em21lYw==?= To: Eric Wong Cc: meta@public-inbox.org Subject: OpenBSD debugging In-Reply-To: <20231023195818.M543558@dcvr> Message-ID: <20231023222143+0200.165893-stepnem@smrk.net> References: <20231018170111+0200.599564-stepnem@smrk.net> <20231018190634.M893199@dcvr> <20231018211801+0200.254938-stepnem@smrk.net> <20231018212319.M51504@dcvr> <20231019104320+0200.219147-stepnem@smrk.net> <20231023195818.M543558@dcvr> User-Agent: Notmuch/0.38 (https://notmuchmail.org) Emacs/30.0.50 (x86_64-pc-linux-gnu) Date: Mon, 27 Nov 2023 12:20:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: I apologize for the late response. On Mon, 23 Oct 2023 19:58:18 +0000 Eric Wong wrote: > Thanks for the info. Just curious, what HW specs (ncpus, RAM) > is available on that system? I wonder if that affects timing > somehow... dmesg: https://dmesgd.nycbug.org/index.cgi?do=3Dview&id=3D7357 ncpus =3D 2 (so it's running the MP (multiprocessor) kernel), 1GB RAM >> (And again, if you want to have a look yourself, I'd be >> happy to give you access to the machine; still the same >> testing OC VM.) > > Unfortunately, my *BSD debugging knowledge is far behind my > Linux; so I'm not sure how much help it'd be... If nothing else, you could do some tests on an otherwise idle machine with good Internet connectivity (unless the connection issues you keep mentioning are mainly on your end, that is). > Some examples of things I miss on OpenBSD: > > * /proc/$PID/fdinfo/$FD_OF_EPOLL on Linux is immensely helpful > for knowing what and how epoll is watching target FDs. I'm > not sure if there's a way to introspect kqueue like that Yeah, most likely there isn't, though I'm not quite sure what exactly "like that" entails. Care to expand a bit upon the immense usefulness mentioned, i.e., how this helps you specifically? OpenBSD fstat(1) prints the kqueue memory addresses, so I suppose a sufficiently determined individual could get arbitrary info from the running kernel based on that, although at that point there are probably better ways to get the address than running fstat... As for existing tools I'm aware of, there's ddb(4) which can dump structures etc. (it has access to kernel symbols), but it's not very convenient for casual debugging/introspection, as it stops everything until you continue from the kernel debugger, so it will mess up the clock etc. Then there's bt(5)/btrace(8), which is a bpftrace clone. It's a work in progress and nowhere near Linux feature-/coverage-wise, but when it works it's nice. AFAIK the most you can currently get from it by default is entry and return for syscalls and a couple dozen static tracepoints. It's possible to enable entry/return for all kernel functions with a custom kernel (which, depending on circumstances, isn't as bad as it sounds: compiling an OpenBSD kernel from scratch is a matter of (tens of) minutes even on a weak machine; it took about 40 minutes in the above VM, single-threaded). Unfortunately there's no support for arbitrary argument access (though it seems to be on TODO), you need to add a custom tracepoint for that (which can be easy enough, e.g. , but again requires a kernel compile). > * Linux strace decodes more struct args info than kdump strace is certainly more featureful, though in the specific case of kqueue/kevent I think kdump does show everything one would expect to see? > * ability to control pathname of core dumps Yeah, the way the OpenBSD knobs have evolved (i.e., sane behavior attainable only for processes with altered U/GID) seems pretty weird, and even though I suspect at least some developers would be able to entertain the thought that the situation isn't optimal (despite the way the recent misc@ thread you participated in turned out), I don't see a good way to improve it without some redesign, i.e. breaking backwards compatibility (adding further knobs on top of kern.nosuidcoredump would make matters even messier IMO). That said, if it's critical for your use case, I think we could patch it locally in the VM easily enough, now that I've set it up for kernel compilation anyway. Same for any custom bt tracepoints or other adjustments I'd be able to help with. In summary, if you ever feel the VM could be of use, just let me know; if you consider your resources better spent elsewhere I certainly understand. --=20 =C5=A0t=C4=9Bp=C3=A1n