From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ePCnKmn4D2azbCQAWB0awg (envelope-from ) for ; Fri, 05 Apr 2024 09:11:05 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Svkip+OX; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 997EE1E0C0; Fri, 5 Apr 2024 09:11:05 -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 80DB51E030 for ; Fri, 5 Apr 2024 09:11:03 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id EA0A0384601E for ; Fri, 5 Apr 2024 13:11:02 +0000 (GMT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id E2195384604F for ; Fri, 5 Apr 2024 13:10:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E2195384604F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E2195384604F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712322623; cv=none; b=S51bUBgwBTjnuCbi+ucE8BZOw7LVcK6ClBSmXOssPUIxc5aK/+0tOc8G7gngt4Npo+tiLk3V9YEMVu2J/rph5HlPVoWAvkGrtETFaE0q3KF33NG3M/pQZjESZZt49yreO1kB3+apcrA1QDjO2zRE4P9xoNJiMcdTw7DbSlR/Djg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712322623; c=relaxed/simple; bh=as2TSOVuOmrvuQJYUM9lFAdN2aWuqvl/2ZSRxUbPJyk=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=UXWPgpstj0wZb2bzNxm3JMVikxF0/f0CgESMH7P5XbtysETeXsuq1y8qnk1OLlJ2i5p5/xbk79t4jRp7ORw4hAC0lDLBlrmS/JyXMGi7Z76qk5cEV8mp9AyBiyATs7wIfxuigal7MkOR93QdgV7rTGUIZK0fcMyfDOFMGyFdQv4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712322621; 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: in-reply-to:in-reply-to:references:references; bh=h+fRM9UQmSVyNcoSqmAtRbr1MMCFcvWXn4sE80Hzj04=; b=Svkip+OXO0gT6oRom1Zf1No7MaPu/+Nl3Si3RpJNrI7wQ162febiQ4wnKEIw3RsO/v464v nvB6rb+4OLt/97ymRVdr+M15LtOkk9eYyZbMgvmu7Z8JanpF0vNTdEB52+fnuT+ZszzGqb cGotsTJZV18yEDImH7U1GQhMt+e/jXA= Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-618-liWOErKZNVatoH1r9CgfKA-1; Fri, 05 Apr 2024 09:10:20 -0400 X-MC-Unique: liWOErKZNVatoH1r9CgfKA-1 Received: by mail-ej1-f71.google.com with SMTP id a640c23a62f3a-a4e05cee8faso90383266b.1 for ; Fri, 05 Apr 2024 06:10:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712322619; x=1712927419; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=h+fRM9UQmSVyNcoSqmAtRbr1MMCFcvWXn4sE80Hzj04=; b=gl8ELE4PS627DzR6/BxTFMwYmUjj4vvrlTVDCd9k6Pq5Qbzo7zUo8V4Xgwq+huUUgo sQZXtF9fu3ezYEw2fPXxI9zslSfTbaf+RnzvNBmQqO9SJ9qP2r5zDX1cUE7a2yx2Ifkz zOXPhkxPNuTnmlzhKJCBHHVY6yiA8BjRgag1b/PO87EOdMHux/XYILWyvxsjNXbjyvhQ VidC0UYB6PUJWwHjC1p9Sc4e8uum4XBW5Wk3+Xw8CJxZXsUGe3J77Qr91gTPN0626bMB zlELa8CS9z/ddSj3lAXo0B2dQEgnpn065laBt4+0169tA6atjGD9higBb3skXN6fV0bA fD4A== X-Forwarded-Encrypted: i=1; AJvYcCUtej4J+mUlTnC9i7dpyERGAnH+j4EucDR46TzWkQSqX8AyKCDLZACVEKwYzMdGSAIdCmk58xHusxABM9VQXEsH9ythh4qIMidvWQ== X-Gm-Message-State: AOJu0YwJmplEGQKud9KUH0X06GLlg2v+ZvjG5gaMP2O3LOCns5t9TmXa gHMSH8hCLW0m4YqPbpv3BMcTLmJq6DgfBWkOGPGMZI6eDdD7xC5eV0jU4V2AO4kvxWaHP+7QjFT eO52Ch4RW6X+1TnUmfjiciNaOovvi7duIn154qTIG7+H49KlDJPud189XZDA= X-Received: by 2002:a50:d54b:0:b0:568:8e22:4eff with SMTP id f11-20020a50d54b000000b005688e224effmr1091786edj.37.1712322618765; Fri, 05 Apr 2024 06:10:18 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE5QK/mL2fbbf30mmEe7uKkcJpLpj6UddrTcS9R5pJWjC4MaMxP+amknAiN326TPo4BnBw7rA== X-Received: by 2002:a50:d54b:0:b0:568:8e22:4eff with SMTP id f11-20020a50d54b000000b005688e224effmr1091767edj.37.1712322618323; Fri, 05 Apr 2024 06:10:18 -0700 (PDT) Received: from localhost (185.223.159.143.dyn.plus.net. [143.159.223.185]) by smtp.gmail.com with ESMTPSA id ef3-20020a05640228c300b0056c53ea5affsm757652edb.77.2024.04.05.06.10.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Apr 2024 06:10:18 -0700 (PDT) From: Andrew Burgess To: "Aktemur, Tankut Baris" , "gdb-patches@sourceware.org" Cc: Tom Tromey Subject: RE: [RFC PATCH] gdb, rsp: clarify a 0-length memory access In-Reply-To: References: <20240321133018.602537-1-tankut.baris.aktemur@intel.com> <87jzlm4f7v.fsf@redhat.com> Date: Fri, 05 Apr 2024 14:10:17 +0100 Message-ID: <87il0w2bwm.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, 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 "Aktemur, Tankut Baris" writes: > On Thursday, March 28, 2024 3:13 PM, Andrew Burgess wrote: >> Tankut Baris Aktemur writes: >> >> > Currently GDB uses a 0-length write access to probe for the 'X' packet >> > support. However, it is not clear from the document what a 0-length >> > read or write attempt should do. Clarify the document that it is >> > an error. Also update gdbserver's implementation to return an error. >> >> We're usually pretty conservative about changing existing remote >> protocol behaviour. >> >> If I understand the current behaviour correctly, we treat the zero >> length access as always succeeding, but you propose to change this to >> always fail. >> >> What's the motivation for this change? Does the existing behaviour >> cause some problem? >> >> Usually, when the docs are ambiguous we update the docs to reflect GDB's >> current behaviour, unless the current behaviour is clearly wrong. >> >> Thanks, >> Andrew > > Hi Andrew, > > The background of the submission is the thread linked below, where Tom expressed > his tendency to think that a 0-length access should be an error: > > https://sourceware.org/pipermail/gdb-patches/2024-March/207411.html OK. But here's my real worry. Right now gdbserver always succeeds for a zero length read/write, and it's possible that there exists other remote targets that have copied this behaviour. If we change the behaviour for this case, and an updated GDB, that expects zero length will result in failure, connects to an old gdbserver (or some other remote target), what happens? Even if *this* patch doesn't introduce a dependency on the new behaviour, future patches might, so the question I think is still a valid one to ask. Maybe we can show that older GDBs would _never_ send a zero length request? In that case maybe this is OK. The solid solution would be to add a qSupported packet to control the behaviour of a zero length access. The default would continue the current "success" strategy, while if the remote supports the new packet the behaviour can switch to a "failure" strategy. Thanks, Andrew > > Thanks > -Baris > > > Intel Deutschland GmbH > Registered Address: Am Campeon 10, 85579 Neubiberg, Germany > Tel: +49 89 99 8853-0, www.intel.de > Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva > Chairperson of the Supervisory Board: Nicole Lau > Registered Office: Munich > Commercial Register: Amtsgericht Muenchen HRB 186928