This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] expected behavior for "bt" command used with "set language ..." ?
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Tom Tromey <tom at tromey dot com>
- Cc: Xavier Roirand <roirand at adacore dot com>, gdb-patches at sourceware dot org
- Date: Tue, 23 Jan 2018 15:51:52 +0400
- Subject: Re: [RFC] expected behavior for "bt" command used with "set language ..." ?
- Authentication-results: sourceware.org; auth=none
- References: <dac19f88-9639-baf1-fa19-3ae115d197a2@adacore.com> <87vafxk3us.fsf@tromey.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