From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id UP3UKNLQi2a2oR8AWB0awg (envelope-from ) for ; Mon, 08 Jul 2024 07:43:14 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=EWZTFSFJ; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 93A0E1E0C3; Mon, 8 Jul 2024 07:43:14 -0400 (EDT) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id A3F041E097 for ; Mon, 8 Jul 2024 07:43:11 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3A8B03850203 for ; Mon, 8 Jul 2024 11:43:11 +0000 (GMT) Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 838CA3861009 for ; Mon, 8 Jul 2024 11:42:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 838CA3861009 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 838CA3861009 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1720438972; cv=none; b=cPkH+VzOSOR/5kxigb9vBWhKyxb+T2ZyhaX5xMakjb4/LI+5j1hoRgiisVsrVBsEKvlTuqsbg8gsgCJ78KVyi3ZLIsRfdOvvM1PHHXQiizx1Vr9q5nNKK7g7+vmDP1ClGt07vVr2gmQfzilshMXL+EakZ90pItauLZymZlBivio= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1720438972; c=relaxed/simple; bh=YtrCoxUb2d59mJQMeBpTNmKr/hg6EmM5xC2FLj0W+50=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=cyQCwJmR9SrX8laNWSYTO1OgYk7Izgl/aqGp0ww+Ztf197J3UVLxE0O8iTZaCj00vh/2+kZ/yEBaHjPkdIUy0bfB0PpsCm6RfAAcrNvQ0uhhPr/Xsg2ZJNvkZaj1elBg6SA/feCeAyyePEiCpuQkY33ncChQfSzgRCYyeRk1P3Q= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sQmld-0000EQ-JQ; Mon, 08 Jul 2024 07:42:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=g/qPABm6TX3ZJzhJnFrIWmOwi6ojlJYeV1Cdqne+t7g=; b=EWZTFSFJsDWU Q/TuFzqVZChI8stz8OSxDRsgDv3fUu2iySOva0KX/F54DaaL/a0VzEgEBrGwN6R5U5iFgmRrC915C YLG4iCmLi2f5nXibJncgXhL/zm4H26Pb6XJQIRWxL/Ei66TYk4q3kHf8ccP4rhsqWhXdXQMOkVLLT Jxg3Ii+Ufj8lij2z18wkzGYmLGxTOArWcu952XXKYOH8kSMWocgrhYzyCiyKkVJqncte4O9wKM5ir UFZZqra6eIBjWJxA5iNZrqF23fKszSOg8T6L7QdK9xg/AAzx2nFLMfGwBOZeh5D8USXvkR+4SJz8F OxTEB1I44//X0Jhl/wwiyw==; Date: Mon, 08 Jul 2024 14:42:46 +0300 Message-Id: <867cdw1555.fsf@gnu.org> From: Eli Zaretskii To: "Schimpe, Christina" Cc: gdb-patches@sourceware.org, felix.willgerodt@intel.com, luis.machado@arm.com In-Reply-To: (christina.schimpe@intel.com) Subject: Re: [PATCH v4 2/2] LAM: Enable tagged pointer support for watchpoints. References: <20240704101736.3074236-1-christina.schimpe@intel.com> <20240704101736.3074236-3-christina.schimpe@intel.com> <86tth58gk7.fsf@gnu.org> <86plrt8d5w.fsf@gnu.org> <86cyns6rpc.fsf@gnu.org> X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org > From: "Schimpe, Christina" > CC: "gdb-patches@sourceware.org" , "Willgerodt, > Felix" , "luis.machado@arm.com" > > Date: Mon, 8 Jul 2024 08:52:17 +0000 > > > > I will try to come up with a section on tagged addresses/pointers in the > > manual. > > > > Thank you. > > Hi Eli, > > I discussed this internally and we still wonder whether we need to document tagged > pointers. I think I missed to mention one important detail, which is that tagged > pointers are no gdb concept but a generic concept: > https://en.wikipedia.org/wiki/Tagged_pointer. > > Do we need to document such generic concepts, too? I think this discussion moved too far off the main issue here. So let me try to bring the main issue back into focus. The original NEWS item said just this: * GDB now supports watchpoints for tagged data pointers on amd64. Let's put ourselves in the shoes of a GDB user, which just happens to run and debug programs on an amd64 machine, and try to imagine what will such a user understand from this entry. Here are some questions which I think will come to his/her mind: . are all the pointers in my programs "tagged"? . if not all pointers are "tagged", when and how will I ever encounter "tagged" pointers in my programs? . what didn't work with "tagged" pointers until now and will work henceforth? We need to give some hints to the readers, either in NEWS or in the manual, that will help them answer these questions. One possibility is just to place the Wikipedia URL in NEWS. Another possibility is to mention "the Intel (R) linear address masking (LAM) feature", which you so abundantly refer to in the commit log and in the comments, but neither in NEWS nor in the manual, and maybe tell how to "LAM57-enable" a program and why is that useful. (If this is described somewhere on the Internet, a URL could replace the actual description.) IOW, please compare the detailed and clear text you wrote for the commit log message and the code comments with what you decided to put in NEWS. The text in the log basically answers all the questions I think a reader will ask him/herself, and even includes what seems to be important details, like which LAM widths are now supported. Yet none of that ended up in our docs. Why not have in NEWS and/or in the manual at least some of that helpful and clearly described information? Thanks.