From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id JSmdGlSLyGgj3wUAWB0awg (envelope-from ) for ; Mon, 15 Sep 2025 17:55:32 -0400 Received: by simark.ca (Postfix, from userid 112) id 58DCA1E0BA; Mon, 15 Sep 2025 17:55:32 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id B6DA71E04C for ; Mon, 15 Sep 2025 17:55:31 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 500CF3858C24 for ; Mon, 15 Sep 2025 21:55:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 500CF3858C24 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by sourceware.org (Postfix) with ESMTPS id 24DAA3858CD1 for ; Mon, 15 Sep 2025 21:54:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 24DAA3858CD1 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 24DAA3858CD1 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.128.49 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1757973293; cv=none; b=LEKHOTgXc64y1esV2znXS2ldJpgQQLCyXcR0JIUmxPVJZoGsDncfdWrwzleQgBi11B+4N0GoWQrspsthnhSfSITBH9jrM9gscU8krpUlWmq2LnqqKOInBw2yJPeuGfxpX7XZkuVvsUGv1jRKjG3JkJ2otrE5DtFxC2qMTG68dto= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1757973293; c=relaxed/simple; bh=ioMXddsTsMClDhOOXYKqRdKBFYcGv6yA4DMfSO9YzBY=; h=Message-ID:Date:MIME-Version:Subject:From:To; b=FWzAQnUSF7LwHTe7O5jjtVX8nILrnM5mHTcX/pDwrWpgSBaSE9vPa+M4uNjy0y7teYKsHzG9ChIebPM2xTXMw7MkbMbdz0qO/MI16vYFCuSAtgZ0XQLu/REkm4zTCpMqotK/plcCkhvlW+FCgBnTRg3GEYfvNLCJdO7s8JzZcKQ= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 24DAA3858CD1 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-45f2acb5f42so12863805e9.1 for ; Mon, 15 Sep 2025 14:54:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757973292; x=1758578092; h=content-transfer-encoding:in-reply-to:content-language:references :to:from:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/Cx6JNwxGs3qkgISmLgoLEFPWyRXbfGLCtc1tR0J59I=; b=aExG8tgjY22nNmC5o4A22e0hq5y+PYR8He8YHr1Nel1YjfUPPYYriL2OcIBngj32JI EFw4xfYqmxKAcIaDBEfZ4zLkL4hlgd/GWjge169sgakz8sDdMupE4lJGvNt9o4S0PdBo 2jfvomT7zLW621PYh5/ReumBMpHR0dz74ZZVVsr8x50BZoC+/ClgHXLxI7DVgAo5YZii ZwTeaCup+A4V+OuIyb9XqqFzT3cqcWZQQNPIfWuF0DMe8MAx3GlDK1LAtjdiKSvJql93 v6aEYfGfQTgRUVad73Z2GIiojaEI63/7dCshkiWVh99EAMjgPA2BEeG5BGfZXy7QuSwF pZ2w== X-Gm-Message-State: AOJu0Yz2e9YDakAHQBvveOR0KCscqzm55OLQorJqiSxCFZvo5Sqm48Uk aj8ZKoSqOHFVWXoq8ktpOyL48i2yfMBn/J271z+Q9uNZqBW4a8T6WkoNjntN5fGJ X-Gm-Gg: ASbGncviW0X1x22CcWW/bhiRlL2SkkLx7fN4C7AOAQ226f/KOhHcq3Qbey8VeIE4Ak2 cQIBiGDjBg2nrKdNZaF5H1wk0wd1EwDrH1h3HLQe4vhKbnK4jyMHqmjaScjigM0cp23xTn2QxnS arvyeXdfORzmuHJKOS/OVd4/eS5zIKGYb3PxBJUcruqTOOLcBMq88zc7OieHRm/F9t6RrHDx0zu T2/MFDQWxIG1HQF2cAy75EbodO+QzDmE7wWe85gzr9wipxpmQonQLahOr2k1sRNKok1TTEbPCnj byV70SgfsvillznT1cFSvXhyCFghNjFiRDm5e/BYoLgmHmL1u0hKOAXOw20UP4EG1Hchgdbd0ae r163PjnXjODTKQnYYdRFHaYBMBUnokHQX215Insex/PujdqaLugSDACOzmmuFz8bv96Ahmk+/NS Udrn60GA3R X-Google-Smtp-Source: AGHT+IGr+sYQpEgyeJ/lwfRknWlfEMMFeVo6Dco84CZukWVOFH9IaKUqVThNHZH0hfdM/VX42qSlug== X-Received: by 2002:a05:600c:3505:b0:45f:2d7b:7953 with SMTP id 5b1f17b1804b1-45f32d512b8mr13245e9.18.1757973291564; Mon, 15 Sep 2025 14:54:51 -0700 (PDT) Received: from ?IPV6:2001:8a0:fad8:400:9f0e:9939:cce1:9ecb? ([2001:8a0:fad8:400:9f0e:9939:cce1:9ecb]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3e9a591a41csm8780507f8f.7.2025.09.15.14.54.50 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Sep 2025 14:54:50 -0700 (PDT) Message-ID: <3e29d575-22c4-42b7-a8e9-2d57b7367a49@palves.net> Date: Mon, 15 Sep 2025 22:54:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Fix nested gdb_caching_proc with args; Fix gdb.rocm/ tests From: Pedro Alves To: gdb-patches@sourceware.org References: <20250915212841.4161603-1-pedro@palves.net> Content-Language: en-US In-Reply-To: <20250915212841.4161603-1-pedro@palves.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org I should have mentioned something here: On 2025-09-15 22:28, Pedro Alves wrote: > --- a/gdb/testsuite/lib/cache.exp > +++ b/gdb/testsuite/lib/cache.exp > @@ -24,26 +24,9 @@ proc ignore_pass { msg } { > > # Call proc real_name and return the result, while ignoring calls to pass. > proc gdb_do_cache_wrap {real_name args} { > - if { [info procs save_pass] != "" } { > - return [uplevel 2 $real_name] > + with_override pass ignore_pass { > + return [$real_name {*}$args] > } The previous code was using "uplevel 2" here. But I'm struggling to see why that is the right level. When gdb_do_cache_wrap is called via gdb_caching_proc => gdb_do_cache, that takes us to the scope of the caller of the gdb_caching_proc, which off hand would seem right. However, when gdb_do_cache_wrap is called directly by gdb.testsuite/gdb-caching-proc-consistency.exp, it takes us to ... the caller of test_proc? So I'm wondering, what could we possibly want to reference from a higher level in gdb_do_cache_wrap that not having the uplevel in gdb_do_cache_wrap would get wrong? A caching proc IMO shouldn't be doing something like taking the name of a variable as argument instead of a value, as then the procedure wouldn't be guaranteed to be idempotent? So I dropped the uplevel, and found that that doesn't cause any testsuite regression. But maybe I'm missing something. If I am, it'd be nice to add a testcase for it. Pedro Alves