Re: [RFC] expected behavior for "bt" command used with "set language ..." ?

[Matt Rice <ratmice@gmail.com>]

On Tue, Jan 23, 2018 at 3:51 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> Xavier> When printing one frame arguments, should we do it using the language
>> Xavier> of the frame, and it may be different for each frame in a single "bt"
>> Xavier> command or should we leave things as they are, and possibly allow the
>> Xavier> "bt" command to display weird values for frame arguments or even
>> Xavier> worse, crash GDB because the user set language manually so he has to
>> Xavier> know what he's doing ?
>>
>> I tend to think the answer should be:
>>
>> * If the language is "auto", then use each frame's language; otherwise
>> * If the user specified a particular language, use that language for
>>   everything.
>
> I don't really have a strong opinion on this. But I thought I'd mention
> that using a language to dump the value of a variable described using
> another language can be a bit iffy, and lead to fairly mysterious
> errors. If I was a fan of FUD, I might even say it can lead to crashes,
> if the code is not careful enough. For instance, who knows what it's
> going to look like asking Ada to print come C++ stuff, or vice-versa...
>
> As a user, the few times I have forced the language was to execute
> one command (eg: print this Ada variable using pure C), and I tend
> to switch back to "auto" asap. But it's easy to forget, and when
> that happens, linking the weird printing in our backtrace back to
> the language change we did a few commands ago may sometimes not be
> all that obvious.
>
> That being said, it looks like this is the behavior we've had for
> quite a while, now, so it confirms the current approach probably
> is not that much of any issue (if at all). Hence the lack of strong
> opinion :).
>
> For now, we'll go ahead with what Tom suggests.

The only strong opinion that I have about this is about an edge case,
where the frame language is not the user specified language and the
frame language is unknown to gdb.  It should prefer the user specified
language upon fallback, rather than e.g. minimal,

this is somewhat implicit in the current behavior, but if it changes,
or you guys carry patches for this.
I thought I would mention it.

>> Xavier> This can also probably be done by adding frame language parameter to a
>> Xavier> lot of language specific functions for each language and finally to
>> Xavier> value_cast but this second solution requires a huge amount of work.
>>
>> That would be good to have but I don't think it ought to be tied to
>> this particular project.  Certainly plenty of other code already just
>> sets and resets the global.
>
> Agreed.
>
> Thanks Tom!
> --
> Joel