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

[Xavier Roirand <roirand@adacore.com>]

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.