From patchwork Fri Jan 27 15:25:33 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pedro Alves X-Patchwork-Id: 63793 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 619AA3857C51 for ; Fri, 27 Jan 2023 15:25:53 +0000 (GMT) X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) by sourceware.org (Postfix) with ESMTPS id BCEDE3858C00 for ; Fri, 27 Jan 2023 15:25:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BCEDE3858C00 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-wr1-f50.google.com with SMTP id y1so5307375wru.2 for ; Fri, 27 Jan 2023 07:25:36 -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:cc:to:subject :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=VG2O6h5L1v0ObvbRKU2J8LcfXRYIDUUJrmFQfS8EjTk=; b=CChEM2fSfhNWVjqJipSgT6dcSbrmP7+GOrqzanuSObjvnu5jEwkGC8QHRXOirybp/x Id0W1ZQSsG9/LNFiDa2Uec2fhdC8BXa4iVKkAUnnIj+P3L1uvVajfn/PBlcJ5hHjVVBo S2efn8p/j1Ji5Vv1Fvt6l6KPTBSQ81GB1I172LpvEI1JvWAdZa3I46X5QNllnjsdLiCa 6MiiEv9cK+CfZryDOJIwW/xLe4uvumvxFIe3IhG/jkMIkMpm/sAirosD7NyngXw152it w1ozJt9YZ84yIbWkuxP53BIfRaHRmbvNxGRsU2iVn5XsNdjHc3pUEYOGjkfF6ZoJuDEQ yh7w== X-Gm-Message-State: AFqh2kpNbtPwPGQi8IOjHHak6JISfs62yrfU5TMSfn+Is6uymuTdBDwF rXHRjZwPRgX2XyjUN67uhann6xHeae4r7g== X-Google-Smtp-Source: AMrXdXv0n7JGcIlHyz9rJqbIfXmuSkomA7FPodmxlz7LWSRO3xzGLboX87iJcPDsZsKgX2qysPz1wg== X-Received: by 2002:adf:e9d2:0:b0:2bd:e6f5:5122 with SMTP id l18-20020adfe9d2000000b002bde6f55122mr33992992wrn.65.1674833134976; Fri, 27 Jan 2023 07:25:34 -0800 (PST) Received: from ?IPv6:2001:8a0:f92b:9e00::1fe? ([2001:8a0:f92b:9e00::1fe]) by smtp.gmail.com with ESMTPSA id n15-20020a5d598f000000b002bdff778d87sm4877734wri.34.2023.01.27.07.25.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Jan 2023 07:25:34 -0800 (PST) Subject: [PATCH v2] Update the 'g' packet documentation To: Tom Tromey , Eli Zaretskii Cc: gdb-patches@sourceware.org References: <20230111183725.2902496-1-tromey@adacore.com> <533a8893-c0b2-ec5a-fa11-f83bf98f4429@palves.net> <87lem645yr.fsf@tromey.com> From: Pedro Alves Message-ID: Date: Fri, 27 Jan 2023 15:25:33 +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: <87lem645yr.fsf@tromey.com> Content-Language: en-US X-Spam-Status: No, score=-10.1 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, 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 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" On 2023-01-13 6:58 p.m., Tom Tromey wrote: >>> -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 >>> > > Pedro> Here, the new text still uses "collected", but lost the reference to trace frames. > Pedro> It seems to me that that will result in people not knowing what "collected" > Pedro> means in this context. > > Yeah, I wanted to get rid of the trace frame note, because it's > confusing -- 'x' can be sent any time, not just a trace frame. Yeah, but then people won't know what "collected" here means. Also, in the normal case you shouldn't really end up with unavailable registers -- if some register really doesn't exist, then the target description should ideally not describe it. How about this version of the patch? It combines your original patch with my suggestions, and also extends it further to describe the normal live target scenario and include a remark about just not including the register in the tdesc. (Note: I did not add an xref for the target description section at the end because there's already one in the preceding paragraph.) From 0d6c9a0b451933042e2b0d28c6a13bac0d044433 Mon Sep 17 00:00:00 2001 From: Tom Tromey Date: Wed, 11 Jan 2023 11:37:25 -0700 Subject: [PATCH] Update the 'g' packet documentation 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. Co-Authored-By: Pedro Alves Change-Id: I863baa3b9293059cfd4aa3d534602cbcb693ba87 --- gdb/doc/gdb.texinfo | 30 ++++++++++++++++++++---------- 1 file changed, 20 insertions(+), 10 deletions(-) base-commit: 1c66b8a03989b963534689ec0a9cce57e419afd5 diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index b5fad2cb16e..2bc4b5b4aa8 100644 --- a/gdb/doc/gdb.texinfo +++ b/gdb/doc/gdb.texinfo @@ -41352,17 +41352,27 @@ 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}. - -When reading registers from a trace frame (@pxref{Analyze Collected -Data,,Using the Collected Data}), 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 +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. + +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 in the trace frame. When reading registers from a live +program, this indicates that the stub has no means to access the +register contents, even though the corresponding register is known to +exist. Note that if a register truly does not exist on the target, +then it is better to not include it in the target description in the +first place. + +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: +registers 0 and 2 are unavailable, while registers 1 and 3 +are available, and both have zero value: @smallexample -> @code{g}