Re: [PATCH v5] [PR mi/29554] New PRINT-VALUES option '--scalar-values'.

[Gareth Rees <grees@undo.io>]

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.