From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 66DDC384AB7B for ; Mon, 22 Apr 2024 19:42:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 66DDC384AB7B 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 66DDC384AB7B 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=1713814983; cv=none; b=YXF2ifoz1YGH72PmKg/mq1mH5h93OamBD2cjx57bg2oHRKUD9YVE8N3QXBqtw6YfjjqlXE6KZY3knw3hlZZOveiTAZ9UnBXswd1e6gQ91tMXv1N28JG0UjVUqyJzLDe+Nd0/CeEpBHeyq+6GrULVRl+EXE9q0g3ATnmU9HhZggE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713814983; c=relaxed/simple; bh=SNw0Jb1c6l95Zn0JNjzmklEwMmNFXEzfwE4fJz5DRuM=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=CEA2ZA+iNfNxTjBgL6i6I/dzJJKa/ax3o5YZjAWPU/EqA4vz/gQymkLZJ9960oYKvWFKppXRoxrusKZRzX7AF6t/RKz0qt7dVwX4uWfaoCqWVfPaxV40XwoP9M4S7ZZi+NLKuRBzUSqPXZrwmB/Lcgvi8NOHeZOqt5ETaeNGRIg= 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 1ryzZ3-000732-LR; Mon, 22 Apr 2024 15:42:58 -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=GbNaXUIITi9qLxRHbCaKCepE55JdhvjEXePTJG/rQxE=; b=Rtx5PBv8WhV+ 0G6Zuiwn7q4djgoSmCwNtPEIuYG2HhaU2uRD7081fEVO99ctUEn/q+tx30a3c/PfbpNamdAhHIadD x1pqV1ZaK4X5kEh8alLkdLPmYdR7tVz2bO4bPDkLh1FIFk2RtdkcrU4wgsaM5RN3TdjE1YbMpiudr Tkl2snX1siFYxCXQknCMTJdBqoqXu+fakMCnIlctDfs6BDdwvQD0bmfZuBeXlHzmq3FGAQhq1aWAT xSqtXenWzqpzb9PNq3x7Hx64et5EY9u7sAhTl+cAPqk9MmYbH+yzTjaa/zfx9jjoHijTPPudoYi+A XZFZqYHOlZWrN4C5VPsqTg==; Date: Mon, 22 Apr 2024 22:42:54 +0300 Message-Id: <864jbt5gld.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves Cc: gdb-patches@sourceware.org In-Reply-To: <9d19b898-9291-4d5b-9aaf-20dbb26493cc@palves.net> (message from Pedro Alves on Mon, 22 Apr 2024 20:00:23 +0100) Subject: Re: [PATCH 02/12] Centralize documentation of error and empty RSP responses References: <20240419151342.1592474-1-pedro@palves.net> <20240419151342.1592474-3-pedro@palves.net> <865xwdbc0r.fsf@gnu.org> <9d19b898-9291-4d5b-9aaf-20dbb26493cc@palves.net> 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 List-Id: > Date: Mon, 22 Apr 2024 20:00:23 +0100 > Cc: gdb-patches@sourceware.org > From: Pedro Alves > > >> +(@samp{$#00}) should be returned. > > > > I don't understand what you mean by $#00, and why that is considered > > and "empty response". I'm probably missing something. > > "$#00" is the raw sequence of characters that is sent over the wire for a > packet with an empty payload. It comes from this: > > A @var{packet} is introduced with the character > @samp{$}, the actual @var{packet-data}, and the terminating character > @samp{#} followed by a two-digit @var{checksum}: > > @smallexample > @code{$}@var{packet-data}@code{#}@var{checksum} > @end smallexample > @noindent > > When packet-data, which is the payload, is empty, you end up with "$#00". > > Note I just moved that sentence, it was already described that way. But we > can certainly improve it. I propose adding "raw character sequence" (see below). > > > > > Also, "should be returned" doesn't really fit the purpose of this > > section, which AFAIU is to describe the standard responses. So > > something like below would be IMO more appropriate: > > > > An empty response means this packet is not supported by the stub. > > > > Makes sense. Like so? > > +@cindex empty response, for unsupported packets > +@cindex unsupported packets, empty response for > +An empty response (raw character sequence @samp{$#00}) means the > +@var{command} is not supported by the stub. This way it is possible > +to extend the protocol. A newer @value{GDBN} can tell if a command is > +supported based on that response (but see also @ref{qSupported}). Yes, this is OK. Thanks. Approved-By: Eli Zaretskii