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 C21FE3858D20 for ; Mon, 30 Oct 2023 15:49:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C21FE3858D20 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 C21FE3858D20 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=1698680947; cv=none; b=h1P5NzLwpESLjfp8DaRfSleMkf2AK0wE0oY+CfZIITPi8M+4yp9yXkXW50hsvUPszaDb+4qCcxk2g3ic6FArcABVN0t80hLoMmvPAJRPY005AZmnOXhGEqS5wWwqUc5SCiSzOqgkB7a7wcONT5VuhIO9yPjzQ/5xLUowbc9XWTA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698680947; c=relaxed/simple; bh=pU+WTqVsVvmy0Mfe3pRVKVcUGOptPkoVk517Vj/Htus=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=QkZHaAicfngobds6NePwofduHJD0pKxfy0gcpyzHRt9/iRglFvuhQjdQv2FepZiO19T/ZKH0Cdylz+sfFKXep2bjkiPXbXhPgGe+3gLg4VNdajjdxXKkxvanMe84k1p5KLU9JFylzkMl9S356eUhl9rS+0denIQK6MHlhuJFjyI= 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 1qxUVm-0001ZC-6L; Mon, 30 Oct 2023 11:49:06 -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=x6vToguok3FXO6A0CPHF6TKaDWCOb+3yCnm3erZfyeM=; b=bmvMSJIMF0ic wM+5TOV11r8aSRoCNawfjm6V8bRPCkoDqtv7xueNXzpycP/mH3iuSaH7sdZD754tgAyFZzvt5IVy6 6jlHwQsrQRrKOXf+R7v1w5fx1tAYXMse04lYQrvOmj4e3YktPPY192uH5dbEOy09sUd9A2iiRP0Q5 zj9Kizddin8Vpeazy173vbDxw2dWW6VDrKhzE6XsRrFeLTE6Jm/SYRPQjZTNgttkJ04de6jOAbkyX q0W3Nim//eLog3JwZshrbyTlJPTBTZucPzpYQR839e5IvSIdrZe1094j6sQS8od0aaf1oiDGz3hWH OBuF0y0tgS+r71TtEilOTA==; Date: Mon, 30 Oct 2023 17:48:45 +0200 Message-Id: <83v8ao9kma.fsf@gnu.org> From: Eli Zaretskii To: Tom Tromey Cc: gdb-patches@sourceware.org In-Reply-To: <20231030150850.2580129-1-tromey@adacore.com> (message from Tom Tromey on Mon, 30 Oct 2023 09:08:50 -0600) Subject: Re: [PATCH] Reword gdb.Frame.read_var documentation References: <20231030150850.2580129-1-tromey@adacore.com> X-Spam-Status: No, score=0.3 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: > From: Tom Tromey > Cc: Tom Tromey > Date: Mon, 30 Oct 2023 09:08:50 -0600 > > I noticed that the docs for gdb.Frame.read_var are mildly incorrect. > They don't really document how the 'block' argument is handled. This > patch tries to correct the oversight. Thanks. > +Return the value of @var{variable} in this frame. @var{variable} must > +be a string or a @code{gdb.Symbol} object. > + > +If @var{variable} is a string, then @var{block} may be provided. In > +this case, search for the variable from that block; otherwise start at > +the frame's current block (which is determined by the frame's current > +program counter). > + > +If @var{variable} is a @code{gdb.Symbol} object, then @var{block} is > +ignored. This is okay, but it left me with an unanswered question: if VARIABLE is a symbol, where does the search for VARIABLE start? does VARIABLE specify its BLOCK or something?