From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 53F0A3858D39 for ; Mon, 13 Mar 2023 17:18:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 53F0A3858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1678727886; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=SgR3sggoheBt/aZMvEDm4owqEQs9cU08hwkEDQvyXaY=; b=cvWj6pZZsJjkF2tKkIJUg+epZ3j2jJ/gwqAjHw2kMy+yjhuwX7c99MOmc6Q8//PRmIcSVb h56YxOlrq7sx7vJ+Kwcl+Oy7+yW5SWefNMcmTCFhEEY4RBuXJd2RNO356IXKMqX2BBaKYq GoqKXb1Cjm4Hv+aHrwWUmAgnu+NeOXc= Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-486-ycODcNIMMeKB4_B9_DDIVg-1; Mon, 13 Mar 2023 13:18:04 -0400 X-MC-Unique: ycODcNIMMeKB4_B9_DDIVg-1 Received: by mail-ed1-f70.google.com with SMTP id h15-20020a056402280f00b004bf9e193c23so18107489ede.11 for ; Mon, 13 Mar 2023 10:18:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678727883; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=SgR3sggoheBt/aZMvEDm4owqEQs9cU08hwkEDQvyXaY=; b=JY+q9MCGw9kKdEurx6QPbT+c9oDAVKZMHGqEAevM8f83rGyUtbs9HB+Jy3fdprmSHd YjA/eptIBrI7gxE1iuo4S1X2rny8pcEIbzFdlA9G+MVzN87iqBUzYozE0CggXBMbH+J9 6yHadx+h/PxCAkfF4BGZw0a3n0EdxFRa9C/J/D7K7AP7tzffHLDKvwM+AsKt0sLffOzN F7cOlAdVAjfPyfMiQfZCbnlSyUGgasszLHSHv6G1ixL/+bCv6qmAItBF2JFS0D9UQqka R0crNIB1eeIj9v1dO3NTod+ugmqyhK4Ljb4uUFMZRiHuRuYDxGfbj49/lhR1r95A3ynu RQJw== X-Gm-Message-State: AO0yUKWSSEHkvStyUHraLGBu1Wl1QEBBbqyuspwzdO9aNCkLd1UAVkYF DoCWfMeCnOoBms75QNEEl8nvvOMn0nXu7O8kj035TqvuWnWGUimAVfJ8c1cnCNJKoxyuY3f6+bq psB+op5i21Kit6X2ejIrKzw== X-Received: by 2002:a17:906:b007:b0:870:d9a:9ebb with SMTP id v7-20020a170906b00700b008700d9a9ebbmr33661794ejy.38.1678727883420; Mon, 13 Mar 2023 10:18:03 -0700 (PDT) X-Google-Smtp-Source: AK7set/wTJaIw2DYTaCOMz8M9AGnIOTJTedpTgkmXiXswoP05/4tkxkPYTmHUffhh9iKm4wJMq6bdA== X-Received: by 2002:a17:906:b007:b0:870:d9a:9ebb with SMTP id v7-20020a170906b00700b008700d9a9ebbmr33661775ejy.38.1678727883155; Mon, 13 Mar 2023 10:18:03 -0700 (PDT) Received: from localhost (95.72.115.87.dyn.plus.net. [87.115.72.95]) by smtp.gmail.com with ESMTPSA id gf4-20020a170906e20400b0092396a853bbsm41478ejb.143.2023.03.13.10.18.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Mar 2023 10:18:02 -0700 (PDT) From: Andrew Burgess To: Eli Zaretskii , Gareth Rees Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v5] [PR mi/29554] New PRINT-VALUES option '--scalar-values'. In-Reply-To: <83r0twzu8r.fsf@gnu.org> References: <87fsftateu.fsf@redhat.com> <20221020174702.514681-1-grees@undo.io> <87bkl3h153.fsf@redhat.com> <83r0twzu8r.fsf@gnu.org> Date: Mon, 13 Mar 2023 17:17:59 +0000 Message-ID: <87v8j4fu48.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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 writes: >> From: Gareth Rees >> Date: Fri, 10 Mar 2023 11:04:42 +0000 >> Cc: gdb-patches@sourceware.org >> >> 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. > > The reason why I preferred #2 is simple: it avoids incompatible > changes in the behavior of existing options. I think we need to be careful not to paint this change as worse than it really is. If we picked option #1 then this would change the output in some cases, so obviously, there could be a user out there that depends on a particular output in a given situation, and any changes will break their use case. But.... ... for a well written front-end, picking option #1 should be a transparent change. They already have to handle passing non-references to non-scalar types. Option #1 simply redistributes which value types fall into which category, it doesn't do anything that we didn't do before. > 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. I agree, we will likely never know with certainty if the existing GDB behaviour was by design, or by accident. That said, my guess would be accident, but I also think that's likely irrelevant here. GDB isn't printing something that's incorrect -- that would clearly be a bug. And GDB isn't crashing -- that too would clearly be a bug. So I think this becomes more a GDB development question: if we release a miss-feature does that mean we have to guarantee to support that miss-feature forever? Or are we allowed to go in an make adjustments? On one extreme we can take the position that once somethings out the door we must NEVER break compatibility. EVER. On the other extreme everything could change with every release. I think the both of these positions would not be good for GDB. Personally, I'm more toward the conservative end. I think stability is good. But I also think we do need to be open to making considered changes, otherwise, we end up carrying around an increasing volume of technical debt that makes future work progressively harder. In this case my think was: 1. The option #1 behaviour is now inline with GDB's CLI behaviour, i.e. hiding the values of non-scalar reference variables by default, 2. A well written application should transparently handle this case anyway as we're not adding a new output format, and 3. The current behaviour (I would say) is clearly unexpected, you ask GDB for simple values only, and you could get back a value of (almost) unlimited size. 4. The option #1 patch already included an MI feature flag. This doesn't stop a badly written MI front-end from breaking, but it does mean the maintainer can query the flag to figure out when to apply the fix-up behaviour. > Introducing a new option is free from this problem. But not free in maintenance cost. If we really feel that the old behaviour is worth saving then adding a new flag isn't the end of the world. I'd just want to make sure we really have considered the alternatives first. Thanks, Andrew