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

[Joel Brobecker <brobecker@adacore.com>]

> 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.

> 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