This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]