From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) by sourceware.org (Postfix) with ESMTPS id 0E3153858409 for ; Fri, 10 Mar 2023 12:58:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0E3153858409 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=undo.io Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=undo.io Received: by mail-ed1-x52a.google.com with SMTP id ay14so19964384edb.11 for ; Fri, 10 Mar 2023 04:58:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=undo.io; s=google2; t=1678453093; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dwOIyrm18TdzMVkkm7IBDLRbZpE4dax1acxxqIlP39g=; b=XJlJCXMD/65QiNXUayxglfoe066FfrpECz+KhUOXJk13tmQozq66kQKj/1ki+o4YuJ a+nmQ1+R+bZ4rfcTxVjMZM5tLlsFyABc3GoRpMHhqRJ1MrWV1xJ6J6SPCa1Dfy1Gsz4t IAcPu/Uvq3a0STIII+w/MhwpKr8arQrJ2iH44rhLZgIc7RzNC6tyWx4azl3y9uFmTp38 4adI0xmmHE2oVE6651zUATw4B8ZbMezdq3dc5mpf3LcyeSwkmSQypyCYlnBJBs7PnMjo 8c1A7iOIvLZBj6liCSrRf5Jof+oa7VLq+B+nYd1XOcP9ydtDc/rJvmbNm/hNoAILyuXV 7VHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678453093; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dwOIyrm18TdzMVkkm7IBDLRbZpE4dax1acxxqIlP39g=; b=VCkZFdrJzw/eDiFdOA7+PWsnoRJv9qCKW4uFYVLA29DxP5LoABIjOnHgDltrhAjLP2 Jk4EypiZsfL4p/LnZDc8PmqJtJ/ybZTQ+nbN9+KP3vdTdjcYYxeqRHiT98RVk7VGjaYg nxEaYgtJ93e7ZdD8P0R/z+EPyIXLBzO3oVleTPIblWp9X196ukaFKKmfFraeA5SNPslz Q+fp2ZjBILNUIGdi/G18N5y/ndug60DlD8NLJCgmnY5Q6QyTxDDOr33Eo+PY0IZ1/9sN Hb46N8P4+Y929521+szNn5cmAEWHHm07hMWy68VRtWzQcLARu3NsYJWqE5TDk3vc5C4F 5V8w== X-Gm-Message-State: AO0yUKVkjjCY7ZjTB9EtR8BOBswRwtxKNsuACEEGqcGY2XkB1XNZBvzB LNSvL64QS8roDgsYNwxoBVEXpNrK3tfK0aSCLQKUjw== X-Google-Smtp-Source: AK7set9V4hfFsnHl5mu6K92PWrW+JCo2GjlwiApaW55M9XSU+KEHmUPdrDuDiGCUPWm7HauHCqCVNqh52iR4Bu5DTsE= X-Received: by 2002:a17:906:274f:b0:8ec:793a:c3f6 with SMTP id a15-20020a170906274f00b008ec793ac3f6mr12288000ejd.11.1678453092680; Fri, 10 Mar 2023 04:58:12 -0800 (PST) MIME-Version: 1.0 References: <87fsftateu.fsf@redhat.com> <20221020174702.514681-1-grees@undo.io> <87bkl3h153.fsf@redhat.com> <83r0twzu8r.fsf@gnu.org> In-Reply-To: <83r0twzu8r.fsf@gnu.org> From: Gareth Rees Date: Fri, 10 Mar 2023 12:58:01 +0000 Message-ID: Subject: Re: [PATCH v5] [PR mi/29554] New PRINT-VALUES option '--scalar-values'. To: Eli Zaretskii Cc: aburgess@redhat.com, gdb-patches@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,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: Eli Zaretskii wrote: > The reason why I preferred #2 is simple: it avoids incompatible > changes in the behavior of existing options. Since it was not really > clear-cut that the previous behavior was a bug, the backward > incompatibility could cause trouble to some application or use case > which didn't consider it was a bug and relied on that behavior. > Introducing a new option is free from this problem. Let me set out an argument for the existing behaviour being a bug. The documentation for the -stack-list-arguments GDB/MI command [1] says: > If print-values is [...] 2 or --simple-values, print the name, type > and value for simple data types, and the name and type for arrays, > structures and unions. There is similar wording for the -stack-list-locals and -stack-list-variables GDB/MI commands. The documentation does not say what happens for reference types, but a natural way to read it is that references to simple data types are simple, and references to compound data types are not simple. That's certainly how I interpreted the documentation when trying to fix the Visual Studio Code stack trace performance issue [2]: my first attempt a pull request for this problem used --simple-values [3] and you can see from the review comments on the pull request that I wasn't the first developer to interpret the documentation in this way: previously Visual Studio Code had used --simple-values but this turned out not to work due to references to compound types being considered simple [4]. This discrepancy between documentation and behaviour seems likely that the current behaviour of --simple-values is a mistake (perhaps the original implementer neglected to consider reference types, because languages like C don't have them). Anyway, this is not a blocker for me: I am happy to implement a new option if that's what the GDB developers agree is the best approach. But I also think the history of work on the Visual Studio Code issue shows that the current behaviour of --simple-values is itself a bug magnet. [1] https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Stack-Manipulation.html [2] https://github.com/microsoft/MIEngine/issues/1349 [3] https://github.com/microsoft/MIEngine/pull/1350 [4] https://github.com/microsoft/MIEngine/pull/673