From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by sourceware.org (Postfix) with ESMTPS id 87E883858C54 for ; Fri, 10 Mar 2023 11:04:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 87E883858C54 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-x536.google.com with SMTP id cw28so18923987edb.5 for ; Fri, 10 Mar 2023 03:04:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=undo.io; s=google2; t=1678446293; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=z4SApyBEmzEf30iXmKeC4Ote/z2JoQARK/Cvr5OzcUE=; b=n3wXFyYGPIn7Ji5cXaNygxqpt3GnBmWAhLuAzA1Tr894ytRGn64fznzbQge/J6Bex3 50b1gYf6dFf9AYGdoef9bi9B3ILNPtE4IObPRYEybFP7MKFlCrNUqCaMTCF6KUiaShF3 6LprwXnUqmto9tJAkXYXkHo7v81IzFVwHiJqFiCnB8FR9K2k+puDQnE4YID15yEX6Hxx WhrRw6pyNJlMZRVt8VONi5UAflyU1pMnjZ1aX1s3TpBGyumZs/Vxsw1SFQl2k3xWU9i7 QGltljpCy0pq9LOnPp+z9ckDJsbWjzD9sXkZrOjE3wtJ3Xxoy2zzQmTLu0ZHHO7XqvlU 4JDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678446293; 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=z4SApyBEmzEf30iXmKeC4Ote/z2JoQARK/Cvr5OzcUE=; b=qDxcppwAXk8zXCNAcXG95T6n4RHplbMMZaWrpLqxWqdQPvcEtOJQsd4HHxu391m9tT GmVYveey/fKeSbom9P76mAZufDfjuOwdKYgIQkTPiRGyGDMPtatLQb8/KlbDFSrqXfMR 6GI8kKXzNXW+cwZOmmj3VZy+hK4ez2ksuzr1LWWN8sVRPzeDj8lsiHLpI2dc0SFlojur YmChxjgFTmoE0h5F8SxrPZazvRUDThFpT4dGjZxFt2TGjFRbm8TieAlfLBe1w+TVf/Lx UZHXf5AQ/QMklKDyA+fMqBUzWxaCpgfwI+qKqxmN4uk8QUVQz1uy6uDcr8mennfPmOdX vctQ== X-Gm-Message-State: AO0yUKWuVAdoZAWeQOwyjIuirK18IBiXHJJz6QUn0mrjjkE7IK9RuXhb KqC9lc4vwEgzlFcDyewrkLEPvXa8AWCXx8VvXEamsA== X-Google-Smtp-Source: AK7set9bpotAoQZAGEIwBe0bONjyvoJdL727/MkhkBo7LuaO3vkzXJf0NyW6UbdrFITxdCUZ3CupFWml5DPk1lU23jQ= X-Received: by 2002:a17:906:7803:b0:8db:b5c1:7203 with SMTP id u3-20020a170906780300b008dbb5c17203mr12953143ejm.11.1678446293236; Fri, 10 Mar 2023 03:04:53 -0800 (PST) MIME-Version: 1.0 References: <87fsftateu.fsf@redhat.com> <20221020174702.514681-1-grees@undo.io> <87bkl3h153.fsf@redhat.com> In-Reply-To: <87bkl3h153.fsf@redhat.com> From: Gareth Rees Date: Fri, 10 Mar 2023 11:04:42 +0000 Message-ID: Subject: Re: [PATCH v5] [PR mi/29554] New PRINT-VALUES option '--scalar-values'. To: Andrew Burgess , Eli Zaretskii Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-4.1 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: Thanks for following up. Andrew Burgess wrote: > I would love to see some more information here about why #2 was selected > over #1. > > I know in V1 and V2 you did implement #1, then in V3 you switched to #2. > > I saw that Eli preferred #2, but didn't seem to offer any reasons why. > > Did you run into some problems implementing #1? Do you think it would > break some MI users? I switched from solution #1 (modify the existing option) to solution #2 (add a new option) entirely because of Eli's comment. For my use case (improving the performance of getting the stack trace in Visual Studio Code), either solution works, and as a new GDB developer I don't have the experience and expertise to make this kind of design decision. I can only presume that Eli had good reasons for his comment, presumably due to concerns about backwards compatibility, and since it doesn't matter for my use case, I went with Eli's stated preference. > I'm happy to go with option #2, but I still think option #1 would be a > better choice. It would change IDE behaviour in some cases, but I don't > see why that change would break any IDEs, and I can't imagine how the > current behaviour can be considered the right thing to do. > > I suspect what we're really doing here is just collecting more technical > debt; just another option '--simple-values' that nobody ever actually > uses, but which we feel we have to maintain forever "just in case". This also makes sense to me, but this is not a decision that I am in a position to make! The experienced GDB developers -- in particular, you and Eli -- need to come to an agreement about which approach is best in this case: do you prefer to take the risk of a backward- incompatible change (GDB/MI clients can no longer get the values for references to compound types in C++ programs using --simple-values) or do you prefer to accept the cost of leaving (what looks like) a mistake to stand forever? I can implement whichever you think is best. For the moment I will prepare a revised patch implementing solution #1 and addressing your other review comments. If Eli can also follow up and help us reach a conclusion on the best design, that would be great.