From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20393 invoked by alias); 2 Dec 2016 11:59:23 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 18032 invoked by uid 89); 2 Dec 2016 11:59:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1714, states, stand X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 02 Dec 2016 11:59:18 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CEEF86196E; Fri, 2 Dec 2016 11:59:17 +0000 (UTC) Received: from [127.0.0.1] (ovpn03.gateway.prod.ext.phx2.redhat.com [10.5.9.3]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB2BxGvv003372; Fri, 2 Dec 2016 06:59:17 -0500 Subject: Re: [RFA] Small improvements to the remote protocol manual To: Tom Tromey , gdb-patches@sourceware.org References: <1473819514-18403-1-git-send-email-tom@tromey.com> From: Pedro Alves Message-ID: <50947c4e-b4f8-a1ca-70bd-5be6e6a70b3d@redhat.com> Date: Fri, 02 Dec 2016 11:59:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1473819514-18403-1-git-send-email-tom@tromey.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-12/txt/msg00080.txt.bz2 Took me this long to get to reading this email... On 09/14/2016 03:18 AM, Tom Tromey wrote: > @@ -36047,10 +36053,11 @@ also the @samp{w} (@ref{thread exit event}) remote reply below. > The process exited, and @var{AA} is the exit status. This is only > applicable to certain targets. > > -The second form of the response, including the process ID of the exited > -process, can be used only when @value{GDBN} has reported support for > -multiprocess protocol extensions; see @ref{multiprocess extensions}. > -The @var{pid} is formatted as a big-endian hex string. > +The second form of the response, including the process ID of the > +exited process, can be used only when @value{GDBN} has reported > +support for multiprocess protocol extensions; see @ref{multiprocess > +extensions}. Both @var{AA} and @var{pid} are formatted as big-endian > +hex strings. For the record, note that: - the format of @var{AA} used to be exactly two hex chars: /* GDB used to accept only 2 hex chars here. Stubs should only send more if they detect GDB supports multi-process support. */ p = unpack_varlen_hex (&buf[1], &value); - The RSP overview states that "Except where otherwise noted all numbers are represented in hex with leading zeros suppressed." I've pondered before about removing all the explicit mentions of hex encoding, in order to make the exceptions stand out. My idea would be that if packets don't mention the formatting of numbers, then people will naturally look for that in general packet formatting description. But in the current state of the manual, it certainly doesn't hurt to be explicit. Thanks for the fixes. Thanks, Pedro Alves