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

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

[Xavier Roirand]

Hello,

While working on a customer issue, I've faced a (weird ?) behavior that 
exists in GDB since the beginning (as far as I can go back in the 
archives) when displaying frame arguments with a language manually set 
by the user.  I'm wondering if this behavior is the right one or if we 
have to enhance it, thus this email.

In the following example, C & Ada are used to explain the case but any 
other languages may be used, the only requirement here is two have a 
program using mixed languages with a function written in language A 
calling a function written in language B.

Notice that, in order to see the behavior, you have to set print 
frame-arguments to all instead of scalar (default).  This setting let 
the "bt" command show details on each frame arguments rather than ... in 
some cases.

Imagine a program where an Ada procedure calls a C function:

src.c:

void break_me (void) {}

pck.ads:

[...]
package Pck is
    procedure Stop_Ada;
    procedure Call_Me (U: in out Unbounded_String);
end Pck;

pck.adb:

package body Pck is
    procedure C_Break_Me;
    pragma Import (C, C_Break_Me, "break_me");

    procedure Stop_Ada is
    begin
       null;
    end Stop_Ada;

    procedure Call_Me (U: in out Unbounded_String) is
    begin
       C_Break_Me;
       Stop_Ada;
    end Call_Me;
end Pck;

Here, the Call_Me (Ada) procedure calls the c_break (C) function

Let's start a GDB session:

(gdb) set language c
(gdb) set print frame-arguments all
(gdb) b break_me
Breakpoint 1 at 0x402518: file src.c, line 4.
(gdb) r
Starting program: foo
Breakpoint 1, break_me () at src.c:4
4	}

Now let's show the backtrace:

(gdb) bt
#0  break_me () at src.c:4
#1  0x0000000000402533 in pck.call_me (u=
       @0x7fffffffe248: {_parent = {_parent = {_tag = 0x429580 
<ada__strings__unbounded__unbounded_stringT+32>}}, reference = 
0x644010}) at pck.adb:12
#2  0x0000000000402750 in foo_r112_041 () at foo_r112_041.adb:7
(gdb)

As you can see, the U parameter in pck.call_me is weird.
GDB uses C printing function because it is using current language which 
is set to C.
In some cases, with current language set to C++, printing backtrace with 
Ada functions/parameters may lead to GDB crash.

When I say using C printing function or Ada printing function it's more 
related to value_cast function which does not know about current frame 
language but only about current global language.

The question I have based on what this session shows is:

When printing one frame arguments, should we do it using the language of 
the frame, and it may be different for each frame in a single "bt" 
command or should we leave things as they are, and possibly allow the 
"bt" command to display weird values for frame arguments or even worse, 
crash GDB because the user set language manually so he has to know what 
he's doing ?

If first proposal is preferred, then using the above example, the 
break_me frame arguments would be printed using C printing function from 
GDB and the pck.call_me frame arguments would be printed using Ada 
printing function from GDB. This would be printed like this:

#0  break_me () at src.c:4
#1  0x0000000000402533 in pck.call_me (u=(reference => 0x644010)) at 
pck.adb:12
#2  0x0000000000402750 in foo_r112_041 () at foo_r112_041.adb:7

This can be implemented for instance by saving the current language & 
mode before printing frame arguments and restored after.

This can also probably be done by adding frame language parameter to a 
lot of language specific functions for each language and finally to 
value_cast but this second solution requires a huge amount of work.

Regards.

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

[Tom Tromey]

>>>>> "Xavier" == Xavier Roirand <roirand@adacore.com> writes:

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.

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.

Tom

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

[Joel Brobecker]

> 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

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

[Matt Rice]

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

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

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel> I don't really have a strong opinion on this. But I thought I'd mention
Joel> that using a language to dump the value of a variable described using
Joel> another language can be a bit iffy, and lead to fairly mysterious
Joel> errors. If I was a fan of FUD, I might even say it can lead to crashes,
Joel> if the code is not careful enough. For instance, who knows what it's
Joel> going to look like asking Ada to print come C++ stuff, or vice-versa...

To provide some context, I've sometimes had to "set lang c" to
investigate what is really going on.  I can't recall ever wanting to do
this for "bt", but certainly I've done it many times with "print".

Overall I think that gdb's model of unified types implies that languages
ought to pass whatever they don't know on to the C printers.  However,
of course it's difficult to know if this really happens in all cases.

Joel> As a user, the few times I have forced the language was to execute
Joel> one command (eg: print this Ada variable using pure C), and I tend
Joel> to switch back to "auto" asap.

Yep.

Joel> That being said, it looks like this is the behavior we've had for
Joel> quite a while, now, so it confirms the current approach probably
Joel> is not that much of any issue (if at all). Hence the lack of strong
Joel> opinion :).

Joel> For now, we'll go ahead with what Tom suggests.

FWIW I also don't have a very strong opinion about this.

Tom

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

[Pedro Alves]

On 01/23/2018 11:51 AM, Joel Brobecker 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 think that this is what makes sense.

The way I see it, "bt" should print frames as-if the user had manually
done a sequence of "up", "frame", "up", frame", ...
And in that case, we print each frame's arguments using the
frame's language (if language is "auto"), because "up" selects a
new frame, and that switches the language accordingly.  Right?

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

IMO, the uncertainty comes from lack of tests.  So instead of FUDing, we
should add some tests to raise the confidence level.

For example, we could have a testcase that picks a couple Ada constructs
that are quite unique to Ada, and then cycle through all languages,
printing the objects.  Same for C++.

And another testcase that calls C++ from Ada, and then does something
like:

while !$outermost_frame
  foreach lang $supported_languages
    gdb_test "set language $lang"
    gdb_test "frame"
  gdb_test "up"

Thanks,
Pedro Alves