From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.freebsd.org (mx2.freebsd.org [96.47.72.81]) by sourceware.org (Postfix) with ESMTPS id A2644385E006 for ; Fri, 27 Mar 2020 19:22:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A2644385E006 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jhb@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 5707C6A207; Fri, 27 Mar 2020 19:22:22 +0000 (UTC) (envelope-from jhb@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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48psDs0wd9z3N2n; Fri, 27 Mar 2020 19:22:20 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-8.local (unknown [IPv6:2601:648:8881:1e90:70cb:195c:670e:3975]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 142BB568C; Fri, 27 Mar 2020 19:22:12 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: [PATCH v3] Add support for "info auxv" on NetBSD To: Kamil Rytarowski , gdb-patches@sourceware.org Cc: tom@tromey.com References: <20200316181710.7542-1-n54@gmx.com> <20200320172739.26705-1-n54@gmx.com> <0e8e2d3c-aaa7-7a1f-6685-cf15753e8bca@gmx.com> <39c2ef17-89b2-7c7e-e806-0085de678c5b@FreeBSD.org> <09e82a84-db6d-3fed-cf4e-67208cb14ff3@gmx.com> From: John Baldwin Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <5047afd8-487b-5084-b3ea-1f95e75bca0d@FreeBSD.org> Date: Fri, 27 Mar 2020 12:22:11 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <09e82a84-db6d-3fed-cf4e-67208cb14ff3@gmx.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 19:22:24 -0000 On 3/27/20 10:04 AM, Kamil Rytarowski wrote: > On 27.03.2020 17:31, John Baldwin wrote: >> On 3/26/20 4:26 PM, Kamil Rytarowski wrote: >>> Ping? >>> >>> On 20.03.2020 18:27, Kamil Rytarowski wrote: >>>> Register nbsd_auxv_parse() that overloads the default (Linux-style) >>>> AUXV parsing. On NetBSD the type parameter is defined as int32_t >>>> for all architectures. >> >> I would tone down some of the rhetoric. FreeBSD uses the default AUXV >> parsing, and I think Solaris does as well, so describing it as Linux-only >> isn't very accurate. >> > > It is phrases as Linux-style, not Linux-only. I would still perhaps drop the paranthetical part as it reads that way I think even with -style vs -only. >> (Similarly, I think the earlier reviews I saw around ptrace() claimed that >> NetBSD was the only OS to use LWPs with ptrace() in the log messages in >> effect which isn't really true as both Solaris and FreeBSD use LWPs >> happily with ptrace(), just using a different convention.) >> > > The pair of (PID+LWP) for getters and setters of registers (among > certain other ptrace operations) is NetBSD style ptrace(2) API design. > This leads to the point that NetBSD is currently the only OS where > get_ptrace_pid() is not compatible (at leat in the current form). It might be a bit of how it was said, the actual text: Unlike most other Operating Systems, NetBSD tracks both pid and lwp. The process id on NetBSD is stored always in the pid field of ptid. If by "track" you mean "the kernel keeps track of LWPs as distinct from processes" (which is how I read "track"), then I think it is inaccurate. >> I would also tone this down a bit, and at least reference the correct >> specification. The ELF spec doesn't define the layout of auxv_t. The >> per-architecture psABI documents do. Also, just saying that you follow >> the spec doesn't help. I would suggest something like: >> >> /* NetBSD-specific parser for AUXV entries. NetBSD always uses an int >> to store the type as defined in the SVR4 psABI specifications rather >> than long as assumed by the default parser. */ >> > > This is toned down compared to obsd-tdet.c, that says: > > /* Unlike Linux, OpenBSD actually follows the ELF standard. */ That may be, but that probably isn't who I would choose as a model to follow. > OK, is this patch fine after rephrasing the above texts? It looks fine to me, but it probably needs an approver such as Tom to ok it. (I can approve FreeBSD-related things, but not really other bits.) -- John Baldwin