From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) by sourceware.org (Postfix) with ESMTPS id 5919B3858C39 for ; Fri, 13 Jan 2023 12:09:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5919B3858C39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f51.google.com with SMTP id k22-20020a05600c1c9600b003d1ee3a6289so17208554wms.2 for ; Fri, 13 Jan 2023 04:09:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HnGQ3/LRYqO25tczS8NSOZHoAAdECJUW+M1l1+uPSYw=; b=jUOy8vsxNKvk2Pep0Vz6OI1vOtSYMWV+GrZuL+jpeDXlfIo0a+X03kMuV3E0jetZCd srLHQ0cRoKDlrH2WWlvBj0BFQyBONEzczk24QynhQBsu4ZtmFLMrDrvT2U5zRgWMxsCP pSqRr+7te+v+JZgrew3lRVNZswhtrkeMdLKGrpihvWkZ/46QD8TndQDRASJFL8HKYUJz ocZ2LizegLlP59DEPLjQRgQmiqpbYTK7bg0W8czPfUMjPj9N9CSiwb9oFLAbRZ9ZgPnX LsobyTOfKFfLH5wftg9QvgSxRgpbRvXFQcALbCxOrATBO0Hb6jZLPwKnCmcxUPVbLRSE EwPw== X-Gm-Message-State: AFqh2kr8UWTH0HRj/Fe9ZwqXUCmIhl3MtZ6NEEX0qMtr/z/pjZ+KvZpK Dm0Qd/as7uZDtq5jkHRV0LPn1TS/ZdURdQ== X-Google-Smtp-Source: AMrXdXtO8WUhzP9don71eRmlIr/5YCkIoIviVWjR/5Timqiff0O+/qBCFjpKa3S8koZGS82xIKAd5g== X-Received: by 2002:a05:600c:3d98:b0:3cf:d70d:d5a8 with SMTP id bi24-20020a05600c3d9800b003cfd70dd5a8mr57407324wmb.6.1673611762813; Fri, 13 Jan 2023 04:09:22 -0800 (PST) Received: from ?IPv6:2001:8a0:f92b:9e00::1fe? ([2001:8a0:f92b:9e00::1fe]) by smtp.gmail.com with ESMTPSA id m25-20020a05600c3b1900b003d9ed49ee2bsm20989856wms.1.2023.01.13.04.09.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Jan 2023 04:09:22 -0800 (PST) Subject: Re: [PATCH] Update the 'g' packet documentation To: Tom Tromey , gdb-patches@sourceware.org References: <20230111183725.2902496-1-tromey@adacore.com> From: Pedro Alves Message-ID: <533a8893-c0b2-ec5a-fa11-f83bf98f4429@palves.net> Date: Fri, 13 Jan 2023 12:09:21 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <20230111183725.2902496-1-tromey@adacore.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-10.6 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,GIT_PATCH_0,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,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: Hi Tom, On 2023-01-11 6:37 p.m., Tom Tromey via Gdb-patches wrote: > The 'g' packet documentation references a macro that no longer exists, > and it also claims that the 'x' response for an unavailable register > is limited to trace frames. This patch updates the documentation to > reflect what I think is currently correct. > --- > gdb/doc/gdb.texinfo | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo > index 9c0018ea5c1..80584241870 100644 > --- a/gdb/doc/gdb.texinfo > +++ b/gdb/doc/gdb.texinfo > @@ -41318,11 +41318,12 @@ Reply: > Each byte of register data is described by two hex digits. The bytes > with the register are transmitted in target byte order. The size of > each register and their position within the @samp{g} packet are > -determined by the @value{GDBN} internal gdbarch functions > -@code{DEPRECATED_REGISTER_RAW_SIZE} and @code{gdbarch_register_name}. > +determined by the target description (@pxref{Target Descriptions}); in > +the absence of a target description, this is done using code internal > +to @value{GDBN}; typically this is some customary register layout for > +the architecture in question. > This part seems fine. > -When reading registers from a trace frame (@pxref{Analyze Collected > -Data,,Using the Collected Data}), the stub may also return a string of > +When reading registers, the stub may also return a string of > literal @samp{x}'s in place of the register data digits, to indicate > that the corresponding register has not been collected, thus its value > is unavailable. For example, for an architecture with 4 registers of > Here, the new text still uses "collected", but lost the reference to trace frames. It seems to me that that will result in people not knowing what "collected" means in this context. I suggest flipping things around a little, like: When reading registers, the stub may also return a string of literal @samp{x}'s in place of the register data digits, to indicate that the corresponding register's value is unavailable. For example, when reading registers from a trace frame (@pxref{Analyze Collected Data,,Using the Collected Data}), this means that the register has not been collected. and then the following sentence, where it reads For example, for an architecture with 4 registers of 4 bytes each, the following reply indicates to @value{GDBN} that registers 0 and 2 have not been collected, while registers 1 and 3 have been collected, and both have zero value: it may be better to tweak it to say something like: For example, for an architecture with 4 registers of 4 bytes each, the following reply indicates to @value{GDBN} that registers 0 and 2 are unavailable, while registers 1 and 3 are available, and both have zero value: