From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 9920C3846078 for ; Fri, 5 Apr 2024 13:05:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9920C3846078 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 9920C3846078 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712322328; cv=none; b=IZdZHLsFMQSzyP8J8ebcZVB5cuYBAdHiaz3hu3/bWSZ8i71blvP7ESE0LDno16pjjvRfOSC32tuido+teYGqoP6lO2CrU2nMwBUbvTzSd1my7kWmPT6hxqXtq5wVVvp8WfxihdbTinod0MB6GddTgeKeRgM1mmL3z74JrZUNC4c= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712322328; c=relaxed/simple; bh=zJ9EroldwXuWhSuk3FG7pPuP5eEbIFPZ8vb1W7xmOc4=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=cYu3Cz5sTlZiEzXZRE7bbEoRGK6cQePZhEDBnwnLI5dQMMBpPdpaPwZlLRMUZXLv8Mfz0j/Kdx0QnqOBWQ1c4iIJ+pUEGh1ieHczOmoY434hFNqkd4AwyiT/vwE5NbJOvA6vaVM0YB4ESfBWm72CdQB/+BErEXR2h2jwuFOYkrM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712322325; 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=Y81LcHjc3LfdsmOPMoM84VSmS6sjJ9TPDj8L2LtUV9Q=; b=WpjRsu8xfb9CpOVI8OZhytJtqDgAQKifAqZjZUeWopxQ7lz7Wsa0AI3nvO/PYOv9pUBLQH q97gy51wQPV8TWlztws7CqB0B7VmT8xBpNTl+lggCyBK0RmTm9eNb+LlKGCIeq+FdzFlSr LBw6zOGMak0tOuxmI7ppjHY1QkG/uEQ= Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-515-TNPV7CpFOh-tjA0rPTjoag-1; Fri, 05 Apr 2024 09:05:23 -0400 X-MC-Unique: TNPV7CpFOh-tjA0rPTjoag-1 Received: by mail-ed1-f69.google.com with SMTP id 4fb4d7f45d1cf-56c5ce6dd4dso1534896a12.2 for ; Fri, 05 Apr 2024 06:05:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712322322; x=1712927122; 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=Y81LcHjc3LfdsmOPMoM84VSmS6sjJ9TPDj8L2LtUV9Q=; b=qkTIAGRpj/sRVyK0uM3Xt/u2cm5i/Nz7GKMs8PEcrZ2dflNqHzShdYJKHp+8LXmmkS AJ5d6/siYN4fK0NqbsHKqldYKUZmubEF6bUOkQMpqzFeCCN0nPcgnFoONRhpQLt8BcDq n2sk/7R4qq3bjOAcFqVNk+fBpXNTdcX+HjxRmchvH+j+OVZi57CKMXWlYichMs6qqH+6 T2Sd7Kbsj2KVHMDeU97VlZzidjaCDDmEA6Djf0qAmFZMldjjOihIxxp4sgJ7rYnaw1LG h4qqoIsog3ZuKs4OX+84bm338J+26fz8OzIS0JRR4j7fup2yld5S+kN2Mz1RPn5oor8I g7uQ== X-Forwarded-Encrypted: i=1; AJvYcCXm8cLVhG1JgXSCp78nap/zcRywSQjJnLiWO3N4Ig0xKr50DtreSE5Bd1wi3FGZLPagyeW17Lc5uKTa2Umshkdx9OMaRwicldLztw== X-Gm-Message-State: AOJu0YywYsOjOieBrFqWjtAMQlUvwo15FgzVYO9zg/yi4erl1o6kFs2+ shUrH7rToiCShniLLhbD1sBRcEf7RYrMQalI1+kTiPSFNsJrx8rKJlVAcT3yey1qlI71rwkDPBD y1T73Os9DKNYxc5UmgOzm8XR1g66BENS1ednKnzDauF/EH3atNyaRB39rXPQ= X-Received: by 2002:a50:d604:0:b0:567:45e2:c4db with SMTP id x4-20020a50d604000000b0056745e2c4dbmr1255206edi.39.1712322322606; Fri, 05 Apr 2024 06:05:22 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGBH7RZG3XNJcEnnJMf+kSZPMAptYWYAFjZLLB6Y0FBYvdKzT3eT/qUEKFVXR7S99ptGXAIWA== X-Received: by 2002:a50:d604:0:b0:567:45e2:c4db with SMTP id x4-20020a50d604000000b0056745e2c4dbmr1255175edi.39.1712322322064; Fri, 05 Apr 2024 06:05:22 -0700 (PDT) Received: from localhost (185.223.159.143.dyn.plus.net. [143.159.223.185]) by smtp.gmail.com with ESMTPSA id co24-20020a0564020c1800b0056e3d80ca71sm8186edb.35.2024.04.05.06.05.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Apr 2024 06:05:21 -0700 (PDT) From: Andrew Burgess To: Tom Tromey , "Aktemur, Tankut Baris" Cc: Tom Tromey , "gdb-patches@sourceware.org" Subject: Re: [PATCH 3/3] gdb, gdbserver: introduce the 'x' RSP packet for binary memory read In-Reply-To: <87o7bagqil.fsf@tromey.com> References: <990be8b42f1f6ca33ffed7a8ae7ead327009d847.1710343840.git.tankut.baris.aktemur@intel.com> <87h6halypk.fsf@tromey.com> <87v85pkmkl.fsf@tromey.com> <87o7bagqil.fsf@tromey.com> Date: Fri, 05 Apr 2024 14:05:21 +0100 Message-ID: <87jzlc2c4u.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 List-Id: Tom Tromey writes: >>>>>> Aktemur, Tankut Baris writes: > >>> I think the probing idea is that you simply try the 'x' command the >>> first time it is needed. If remote sends an empty response (not an 'E' >>> response), then the packet isn't supported, so you disable it and retry >>> with 'm'. >>> >>> This is documented in the Overview node: > >> Yes, I get this idea, and the 'X' packet actually uses it. My concern there is >> that (1) sending this packet with an arbitrary address and length 0 seems too >> artificial; (2) using the proposed reply format, the target would send an empty reply >> both when it does not recognize the packet and when it recognizes because the length >> argument in the probe is 0 (the same problem would exist with the 'm', 'p', 'g' packets >> if we were to probe them). This would not be an issue if we decide to force the reply >> to always start with a marker character, as suggested in Ciaran's email. > > I definitely think that gdb should not send an 'x' packet with an > arbitrary address and a length of 0. > > Instead the idea is that if the packet is not explicitly forbidden > (either via a gdb command or by previous probe failure), just attempt to > use this packet for the first memory read. > > If the remote reports the packet as unsupported, fall back to the 'm' > packet and carry on. The alternative to this would be to add a qSupported feature for the 'x' packet and choose m/x based on the qSupported reply. I mention this only for completeness really. I've replied in another thread that I think we should adopt a prefix character to avoid needing to escape 'E', but this would also mean we never get an empty reply, so probing would work fine. > I think the docs should be explicit about what a 0-length read means. > I tend to think this should just be an error. I don't have a firm opinion about whether this _new_ packet should give a success or failure for zero length access. And I'm not convinced it really matters, so long as it's documented!! (I haven't checked your patch, so you might have already done so). Success would have the benefit of matching existing behaviour, so I'd be slightly more inclined to take that approach. Thanks, Andrew > > I also prefer Ciaran's idea for the response packet. I didn't realize > other packets already did this or perhaps I would have suggested it. > > thanks, > Tom